(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
27 December 2001 (27.12.2001) 




PCT 



(10) International Publication Number 

WO 01/99349 A2 



(51) International Patent Classification 7 : H04L 12/24 

(21) International Application Number: PCT/US0 1/18669 

(22) International Filing Date: 7 June 2001 (07.06.2001) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 

60/212,126 
09/826,602 



1 6 June 2000 ( 16.06.2000) US 
5 April 2001 (05.04.2001) US 



(71) Applicant (for all designated States except US): SECU- 
RIFY, INC. [US/USJ; 1 157 San Antonio Road, Mountain 
View, CA 94043 (US). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only); COOPER, Geof- 
frey [CA/US]; 2542 Webster, Palo Alto, CA 94301 (US). 
SHAW, Robert, Alien [US/US]; 2237 Voa Maderos, Los 
Altos, CA 94024 (US). VALENTE, Luis, Filipe, Pereira 
[US/US]; 2903 SevysonCourt, Palo Alto, CA 94303 (US). 
SHERLOCK, Kieran, Gerard [US/US]; 455 Colorado 
Avenue, Palo Alto, CA 94306 (US). 



(74) Agents: GLENN, Michael et al.; Glenn Patent Group, 
Suite L., 3475 Edison Way, Menlo Park, CA 94025 (US). 

(81) Designated States (national): AE, AL, AM, AT, AU ? AZ, 
BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, 
DM, HE, ES, FT, GB, GD, GE, GH, GM, HR, HU t ID, IL, 
IN, IS, JP t KE, KG, KP, ICR, KZ, LC, LK, LR, LS, LT, LU, 
LV, MA, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, 
RO, RU, SD, SB, SG, St, SK, SL, TJ, TM, TR, TT, TZ, UA, 
UG, US, UZ, VN, YU, ZA, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS t MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, F[, FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG). 

Published: 

— without international search report and to be republished 
upon receipt of that report 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



3 

On 
m 

ON 



l-H (54) Title: ASSESSMENT TOOL 
O 

O ( 57 ) Abstract: A method and apparatus forallowing a technique for continuously assessing the security of a network to be applicable 
^ to network assessment, by capturing and classifying large volumes of network traffic based on a formal policy, and applying such to 
both long-term and short-term network assessment. 



WO 01/99349 



PCT/US01/18669 



Assessment Tool 

BACKGROUND OF THE INVENTION 
5 TECHNICAL FIELD 

The invention relates to computer network assessment. More particularly, the 
invention relates to a method and apparatus for capturing and classifying 
large volumes of network traffic based on a formal policy, and applying such 
10 to both long-term and short-term network assessment. 



DESCRIPTION OF THE PRIOR ART 

Networked information systems are an essential part of many organizations. 

15 Critical systems, services, and information resources all require protection 
that depends on effective orchestration of a variety of factors: network 
architecture, security products, site security, administrative procedures, end 
user responsibility, and more. A network security policy is an explicit plan of 
how to accomplish this multi-faceted protection, what objectives the plans 

20 should meet, and what assets are being protected. 

To manage a network, an end user needs to know and understand what is 
happening on the network. Most security holes come from unexpected, 
misconfigured, or unauthorized services, for example, from a high-port telnet, 
25 a new service added in, a rogue server, and/or a misconfigured workstation. 
The end user does not know what is the unauthorized network traffic. 
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Security administrators need tools to help them formulate site security policy 
and to translate the policy into monitoring and enforcement mechanisms. 
They need to be sure that the computer enforced policy - often cobbled 
5 together from a plethora of disjoint access control mechanisms - matches 
their enterprise policy, all too often specified in a loose natural language or a 
set of unwritten principles. This leads to confusion as to why access is being 
granted or denied to particular resources and may lead to unintentional 
breaches of security. 

10 

In addition to monitoring network system traffic, it is important for network 
analysts to assess their network's configuration. A discussion on current 
techniques for network assessment follows below. 

15 A conventional network assessment visit determines the customer network 
using the following information: 

1) Network security scanning technology, e.g. port or vulnerability scans; 
20 2) Customer interviews; 

3) Inspection of customer log files, perhaps using machine aggregation and 
filtering; and 

25 4) Occasionally, inspection of customer log files and network traffic. 
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As a matter of practicality, the information is typically derived from the first 
three of these items. Customer log files and network traffic is of a volume so 
great that it is impractical to examine it in a short assessment visit. 

5 The weaknesses such conventional methods are as follows: 

Vulnerability Scans 

Network vulnerability scanners only detect certain types of known 
vulnerabilities. Such vulnerabilities are generally not detected directly, but are 
10 inferred based on host responses to a series of network packets sent to hosts 
by the scanner. This process does not directly ensure that data traffic on the 
subject network matches expectations, either explicit or implicit. 

Network vulnerability scanners cannot see a host if it does not respond to 
15 packets. A host that is only a source of network packets, such as, for 
example, a rogue router, is not visible to a scanner. Hosts which are turned 
off or otherwise temporarily disconnected, such as, for example, workstations 
and laptops, are often missed by vulnerability scanners. This problem is 
compounded by the fact that scans are often scheduled for non-work hours in 
20 order to alleviate customer fears that the scans will somehow impact 
production systems and organizational mission. 

Network scanners typically return a large volume of vulnerability information, 
based on all possible configured elements in a network. The scanner tools 
25 cannot currently interpret those vulnerabilities in light of business 

requirements which the subject systems are intended to support, or even for 

3 
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the specific network architecture of which those systems are a part. The scan 
results must be reviewed manually by a security analyst, who applies a 
knowledge of the business requirements and network architecture to an 
interpretation of those results. Such manual process is error-prone because 
5 the volume is so great that problems may be overlooked. 

Another problem is that the scan derives only vulnerabilities, not network 
usage patterns. Therefore, the scan cannot detect security problems that are 
attributable to human behavior, but only those scans that result from 
10 misconfigured systems and/or systems which have documented design 
problems. 

Network scanners cannot diagnose incorrect client usage of software. For 
example, network scanners cannot detect whether web servers are being 
15 used with invalid ciphersuites, whether 40-bit browsers are in use, and 
whether a given telnet port is accessed only by a management station. 

Network scanners must be targeted to particular subnets. If a customer has 
forgotten to mention a subnet, the scanner does not notice it. 

20 

Customer Interviews 

Customers may not provide the network analyst complete or accurate 
information, either because the customer forgot details, because the 
information is not known to the customer, or because the customer does not 
25 understand the importance of giving the information to the analyst. 
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Customer interviews at best can provide descriptions of overt usage of subject 
systems, and generally not covert usage. Often, formal policies of the 
organization are not even documented, much less promulgated, audited and 
enforced. 

Hidden agendas, office politics, and other factors also can affect the success 
of the interview process. 



Host Inspection 

10 Inspecting host configuration files is a time consuming, manual process that is 
subject to human error. In the assessment of any large network, it is 
impractical to include an inspection of the configurations for more than a few 
critical systems. 



15 Once again, inspection of host configurations does not reveal completely 
intended usage of the subject systems. The configurations must be analyzed 
within the context of the business requirements and overall security 
environment of the organization. This manual process is very human 
dependent and prone to error. 

20 

x Log File Inspection 

Log file inspection can provide great insight into the workings of network 
components. Machine-based aggregation and filtering systems can speed 
this process. However, logs provide only a components' own view of its 
25 status. If a component is misconfigured, the log data from the component 

cannot be trusted. Log data'may also be subject to modification by an 

5 
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attacker who has penetrated the machine and is seeking to mask his 
presence. 

In addition, because log aggregation systems work in cooperation with the 
5 components that generate the information, they require configuration changes 
to every component that they examine. Also, they are unable to detect when 
a component is added to the system. 

Such techniques of performing network assessments generally are limited in 
10 their ability to determine actual security threats to information systems. 
Generally, they represent the state of the art and are indicative of best 
practices within the security community today. 

A way to reduce or eliminate the confusion described above is by providing a 
15 user-friendly and, yet, rigorous way of specifying security policy, as well as 
providing tools for monitoring and enforcing the security policy. 

It would be advantageous for a network policy to provide the definition of 
normal traffic on the network. 

20 

It would be advantageous to provide a monitoring mechanism that lets an end 
user determine and understand traffic and/or activity on a network. 

It would be advantageous to provide methods and system that, when given 
25 known network characteristics, thereby spots intruder access, and track 
changes to a network. 

6 
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It would be advantageous to provide a policy generator tool that assists an 
end user in generating security policy for a network. 

5 It would be advantageous to provide a tool that automatically converts a 
network security policy into English language representation. 

It would be advantageous to provide a tool that allows an end user to query 
network traffic data. 

10 

It would be advantageous to provide a technique for transmitting an event 
description of network traffic from a source file or data stream to a target 
destination, such as a network policy engine. 

15 SUMMARY OF THE INVENTION 

A method and apparatus for allowing a technique for continuously assessing 
the security of a network to be applicable to network assessment, by 
capturing and classifying large volumes of network traffic based on a formal 
20 policy, and applying such to both long-term and short-term network 
assessment. 

The Invention can be a component of a network security policy monitoring 
system and method that comprises supportive features, algorithms, and tools. 
25 The monitoring system is ideally suited for network and security assessments 
or long-term monitoring where real network traffic is analyzed to identify 

7 
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abnormal traffic patterns, system vulnerabilities, and incorrect configuration of 
computer systems on the network. The monitoring system listens on a 
network, logs events, and takes action, all in accordance with a rule based 
system-wide policy. The monitoring system provides a technique that is able 
5 to incorporate external sources of event information, such as are generated in 
log files of other network components. The inventive technique of the 
monitoring system gets protocol information, which can make it more 
meaningful to a network administrator. It sends data upstream to an event log 
and interprets the data. It listens to secure protocols and can identify 
10 encryption quality of service parameters. It extracts basic security 
parameters, such as, for example, network events, and passes them to a 
policy manager component. 

The policy manager component implements system-wide policies, based on 
15 monitored system or enterprise traffic. The policy manager component 
provides a trust manager that takes as its input a security policy defined as a 
set of policy rules and a set of credentials, and that is capable of processing 
requests for trust decisions, i.e. evaluating compliance with the policy. Unlike 
other trust management systems, the monitoring system is designed to be a 
20 passive monitor of network traffic. As such, it need not be installed on target 
hosts or integrated into existing applications. 

Two key aspects of the policy manager component are provided. One aspect 

is a unified view of the interaction between two principals across a stack of 

25 protocol areas, each area covered by discrete policy rules. The final trust 

decision applied is based on policy rules that better fit the entire interaction. 

8 
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The second aspect comprises the policy manager's policy definition language 
that supports the monitoring and auditing of a network's activity in addition to 
traditional access/denial authorization decisions. 

5 The policy definition language is described in A Declarative Languag e for 
Specifying A Sepurity, U.S. patent application serial number 09/479,781, 
(01/07/00). The policy definition language is discussed herein to the extent 
necessary to explain such language to those skilled in the art in connection 
with the invention and the monitoring system disclosed herein. The 

10 declarative language system comprises a language as a tool for expressing 
network security policy in a formalized way. It allows the specification of 
security policy across a wide variety of networking layers and protocols. 
Using the language, a security administrator assigns a disposition to each and 
every network event that can occur in a data communications network. The 

15 event's disposition determines whether the event is allowed, i.e. conforms to 
the specified policy or disallowed and what action, if any, should be taken by a 
system monitor in response to that event. Possible actions include, for 
example, logging the information into a database, notifying a human operator, 
and disrupting the offending network traffic. Further details of the policy 

20 definition language can be found in the patent application cited herein above. 

Unlike Intrusion Detection Systems (IDS) systems, which look for the 
signatures of known attacks, the monitoring system herein is focused on 
defining allowed traffic patterns and how to handle events that deviate from 
25 those patterns. 
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The monitoring system comprises, but is not limited to six major features and 
tools. The first feature discussed is auto-conversion of policy language, 
whereby policy language is converted to an English language representation. 
Next, an algorithm for efficient rule evaluation is provided. Then, a 
5 credential/assertion optimization technique is provided. A policy generator 
tool is provided. An embodiment in which the monitoring system is used as 
an assessment tool is provided. Finally, a technique for secure sensitive 
event extraction from protocol monitoring is provided. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1a is a schematic diagram of components of the system according to the 
invention; 

15 Fig. 1b is a schematic diagram of components of the system according to the 
invention; 

Fig. 2 is a high level workflow flow diagram according to the invention; 
20 Fig. 3 is an example of a policy wizard dialog box according to the invention; 
Fig. 4a is an example of a policy wizard dialog box according to the invention; 
Fig. 4b is an example of a policy wizard dialog box according to the invention; 

25 

Fig. 5 is an example of a policy monitor dialog box according to the invention; 

10 
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Fig. 6 is an example of a query tool dialog box according to the invention; 
Fig. 7 is an example of a query tool dialog box according to the invention; 

5 

Fig. 8 is an example of a query tool dialog box according to the invention; 
Fig. 9 is an example of a query tool dialog box according to the invention; 

10 Fig. 10a is an example of a policy wizard dialog box according to the 
invention; 

Fig. 10b is an example of a policy wizard dialog box according to the 
invention; 

15 

Fig. 10c is an example of a policy wizard dialog box according to the 
invention; 

Fig. 1 1 shows a high-level view of an example network according to the 
20 invention; 

Fig, 12 shows an algorithm according to the invention; 
Fig. 13 shows a flow diagram according to the invention; 

25 

Fig. 14 shows an algorithm according to the invention; 

1 1 
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Fig. 15 shows a high level schematic diagram according to the invention; 
Fig. 16 shows a schematic diagram of process flow according to the invention; 
Fig. 17 is a block schematic diagram according to the invention; 

Fig. 18 is a high level flow diagram of the preferred output section according 
to the invention; 

Fig. 19 shows a schematic diagram according to the invention; 

Fig. 20 is an example of a dashboard according to the invention; 

Fig. 21 shows an example of a tear off console according to the invention; 

Fig, 22 shows an example of an events summary view according to the 
invention; 

Fig. 23 shows an example of a conformance event details page according to 
the invention; 

Fig. 24 shows an example of a protocol event details page according to the 
invention; 

1 2 
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Fig. 25 shows an example of an events summary page containing a pop up 
description according to the invention; 

Fig. 26 shows an example of an events summary page containing a pop up 
5 description according to the invention; 

Fig. 27 shows an example of a conformance event details page containing a 
pop up description according to the invention; 

10 Fig. 28 shows an example of an alert details page according to the invention; 

Fig. 29 shows an example of a violators chart and table page according to the 
invention; 

15 Fig. 30 shows an example of a targets chart and table page according to the 
invention; 

Fig. 31 shows an example of an advanced search dialog box according to the 
invention; and 

20 

Fig. 32 shows an example of a link to the advanced search dialog box 
according to the invention, 

DETAILED DESCRIPTION OF THE INVENTION 



25 The invention is a security policy monitoring system and its supportive 
features, algorithms, and tools. It is ideally suited for network and security 

13 
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assessments where real network traffic is analyzed in order to identify 
abnormal traffic patterns, system vulnerabilities, and incorrect configuration of 
computer systems on the network. The system listens on a network, logs 
events, and takes action, all in accordance with a rule based system-wide 
5 policy. The system is able to incorporate external sources of event 
information, such as are generated in log files of other network components. 
The system gets protocol information, which can make it more meaningful to a 
network administrator. The system sends data upstream to an event log and 
interprets the data. The system listens to secure protocols and can decrypt a 
10 session if a key escrow facility is available. The system extracts basic 
security parameters, such as, for example, network events, and passes them 
to a policy manager component. 

An important part of understanding the invention is understanding network 
1 5 security terminology for policy monitoring. See Table A below. 

Table A 

Terminology 

20 

Network Event: One complete transaction on the network, such as a FTP connection 
or a HTTPS transaction. Each network event has several component protocol 
events. 

25 Protocol Event: A transaction at one protocol level. For example, a network event 

that represents an FTP connection has protocol events representing an IP 
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association, a TCP connection, an FTP control connection, and several FTP control 
commands. 

Initiator, Target: The endpoints of a network event or protocol event 

Credential: An identification of the initiator or target of a protocol event at a particular 
protocol level. For lower-level protocols, credentials are, for example, IP addresses 
or UDP port numbers. For higher level protocols, credentials are, for example, user 
names, file names, or public key certificates. 

Association: A placeholder for a transaction run over a datagram-based protocol 
such as IP, ICMP or UDP. The invention herein constructs an association to collect a 
conversation between two hosts, or processes in the case of UDP. It is noted that 
when the invention misses any data packets between the two communicating 
computers, it might not be able to determine the initiator and the target of the 
association. 

Associative array. A list of value pairs where each associative array entry is Indexed 
by the first element of Its value pair, which is called the key. Keys are stored in a hash 
table to make lookups efficient Irrespective of the size of the associative array. 

Rule: A policy rule governs a specific interaction, or set of interactions, between two 
communicating entities. The invention evaluates policy rules against protocol events 
to determine if the latter conform to the active security policy. 

Disposition: The policy definition of what action or state change needs to take place 
in response to a network event. 

Policy Domain: A top level segmentation of a network, roughly akin to a cloud-like 
object in a network diagram, which hides internal detail. Within the policy domain 
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communities of hosts provide or access services. One community of hosts defines 
the limits of the domain. 

Monitoring Point: A point within a policy domain where it will be possible to plug a 
5 machine into the network in order to collect packet data. 

Communities of Hosts: A mechanism for grouping hosts that have a similar function, 
e.g. all web servers or all NT workstations. 

10 Perimeter Eiemeni: A hardware device that allows access to and from communities 

of hosts outside a policy domain. Examples of perimeter elements are firewalls and 
routers. 



Poiicy Language: A policy language is used to create a formal specification of a 
15 network security policy. The preferred embodiment of the invention incorporates the 

policy definition language of U.S. patent application number 09/479,781, filed 
01/07/00, entitled, "A Declarative Language for Specifying A Security Policy. 1 ' It 
defines first class objects such as rules, credentials and dispositions. It is based on 
s-expressions, which are LISP-like parenthesized expressions. 

20 

Rogue server: A machine introduced to a network that is not authorized to be on that 
network. 



Rogue router: An unauthorized router that is added to a network, providing an 
25 alternate path into the network. Typically occurs through misconfiguration of switches 

or dialup connections. 



Real-time monitoring: Reading packet data off a network and processing it to events 
in a stream, so that an event appearing in the network causes a corresponding event 
30 in the stream a short time later. 
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DLL: Any kind of a dynamically linked library 

System Overview 

5 The preferred embodiment of the invention translates traffic on the network 
into protocol events that are themselves combined into network events. As 
protocol events are detected, they are compared against a policy. The policy 
specifies a disposition of the network event, as defined by the observed series 
of protocol events. Information about the protocol events, the network event 
10 and its disposition is stored in a database. This database of network traffic 
information can be mined for policy violations. 

This preferred embodiment of the invention is described with reference to Fig. 
1a. Fig. 1a is a schematic diagram of components of the system according to 

15 the invention. The system comprises a policy monitoring component 100 that 
takes as input a policy file 105 that has been generated using a policy 
generator wizard 110 or other means, and a file containing network packet 
dump data 115 that has been collected from an observed network 125 by a 
packet capture 126, or that has been processed by a protocol monitor 

20 processor 127. The system can also process packet event data from the 
observed network 125 in a continuous real-time mode, without first storing 
packet data to a file. 

The policy monitoring component 100 comprises a policy manager 
25 component 106 that itself comprises a parser 101 for parsing the policy file 
105, a policy engine for 102 for assigning policy dispositions to network 

17 
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events, and a logger 103 for determining how to log the information processed 
by the policy engine 102, according to an input logging policy 130. It also 
comprises a database 104 for storing synthesized information of the packet 
dump's 115 conformance to the specified policy 105 performed by the policy 
5 engine 102, where it can be mined with a query tool 135. It also comprises a 
report script component 160 for querying the database 104 and creating 
reports 161, and an alarm script component 155, for generating alarms based 
on the severity of the disposition assigned to network events. 

10 An equally preferred embodiment of the invention also comprises a parser 
tool 150 that takes the policy specification file 105 as input and automatically 
generates an English description of the policy 151 for the end user. The 
parser tool 150 is optional. 

15 An equally preferred embodiment of the invention also provides a secure Web 
server feature 162 for the end user to review reports from the end user's host 
computer 163. The secure Web server feature 162 comprises the Web server 
164 and a report database 165 that hosts the reports 161 generated using the 
report script 1 60. The Web server feature 162 is optional. 

20 

An equally preferred embodiment of the invention provides secure 
management connections (141, 142) and a secure management host 140 for 
managing the policy monitoring component 100 and the combination of the 
network monitoring components 128, respectively. 

25 
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Fig. 1b shows a simpler embodiment of the invention, wherein the parser tool 
150 and the secure Web server feature 162 are omitted. 

The default action of the policy engine 102 is that it denies all traffic. The 
5 policy 105 opens holes in this denial to allow permitted traffic to flow. 
Although the policy engine 102 assigns a single disposition to an entire 
network event, the protocol events are significant. As network data 115 
arrives, the policy engine 102 interprets protocols and generates updates of 
protocol event information. The policy 105 is consulted as each new piece of 
10 information arrives, so that the earliest determination of disposition is reached. 
For example, if the policy 105 states that a given IP address may not 
communicate with another IP address, the policy 105 can generate a 
disposition immediately upon receiving the first packet 115 of the network 
event. 

15 

To aid policies in early determination of disposition, the policy language 
divides dispositions into immediate and final. An immediate disposition fires 
immediately, Le. its value becomes associated with the network event right 
away. A final disposition sets a bookmark to itself as the latest and best 

20 disposition. When all protocol events are processed without an immediate 
disposition, the last bookmark set is the disposition that is applied to that 
network event. Immediate dispositions are designed to generate early results 
and to allow policy writers to issue a definitive disposition for the network 
event based on the information received up to that point. Final dispositions 

25 allow for the possibility that a better disposition might be determined later on. 

In other words, they allow the policy engine 102 to make a more informed 

19 
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decision based on additional protocol events that might be received as the 
network event progresses. 

Overview of the Components 
5 An overview of main components of the preferred embodiment of the 
invention is discussed below with reference to Fig. 1 . 

Policy Generator 

The preferred embodiment of the policy generator component 110, also 
10 referred to as policy wizard, is a program that makes an end user readily able 
to generate a first-pass policy for a new site. Policy information is input into a 
set of dialog boxes and a policy is generated. The wizard enables the end 
user to generate policy based on what can be considered gross 
characteristics of a network at the IP level, such as, for example, policy 
15 domains, communities of hosts, servers, subnets and firewalls, as well as at 
the UDP/TCP service level. For example, such network characteristics can 
comprise communities of hosts that can access certain services on server 
hosts. 

20 Once a policy has been generated with the wizard, it is output in the policy 
specification language 105 so that it may be directly processed by the policy 
monitor component 100. The policy wizard 110 is also able to save files at 
the wizard level, i.e. such that the policy may be refined in the wizard and re- 
generated. 

25 

Policy Monitor 

20 
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The policy monitoring component 100 comprises a suitable user interface, 
such as an MFC-based front end or a command line interface, and the policy 
manager 106. The policy manager 106 performs the actual examination of a 
sequence of event updates stored in a file or transmitted in a continuous 
stream 115 in the context of a policy specification 105 and signals the 
adherence to the policy via records written to the database 104. 

Network Monitor 

The network monitor component 127 provides the following capabilities: 

• Streams-based interpretation of packet dump data 126 in, for example, 
DMP format; and 

■ Packet- and connection-based textual logging of protocol information. 
Logging is selectable by protocol and may be enabled only for one or more 
connections. In another embodiment of the invention, the network monitor 
127 can perform serialization of event data. That is, the network monitor 
106 can process a packet capture file 126 into a series of event updates 
that contain only the salient security details for processing by the policy 
monitor 100. The resulting file is significantly smaller than the original, for 
example, approximately 1/20 ,h to 1/1 00 th the size of the original. It is also 
possible for sensitive data, such as passwords and documents, to be 
removed from the file. However, it should be appreciated that the original 
packet capture file is needed to perform full analysis. 
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In another embodiment of the invention, the network monitor 127 can read 
packet data directly from observed network 125, generating a continuous 
stream of event updates for the policy monitor 100. This stream operates in 
real-time so that the policy monitor 100 processes events shortly after they 
5 happen on observed network 125. 

It should be noted that the network monitor 127 can be used as a standalone 
tool, but typically is invoked from within the policy monitor component 100 and 
the query tool 135 in normal operation of the invention. 

10 

It should also be noted that the network monitor and the policy monitor may 
run on the same machine. 

For a more detailed discussion on the internals of the network monitor, refer 
15 to the section, below entitled "Network Monitor Internals Descriptions." 

Query Tool 

The query tool 135 allows the end user to view the data that has been stored 
in the database 104 by the policy manager 106. 

20 

Policy Compiler 

The policy compiler performs syntactic and semantic checking of a policy 
specification. Upon successful compilation the compiler as controlled by 
runtime arguments, may: 

25 
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• Generate a DLL containing a compilation of credential and condition 
verification code; and 

• Generate a pseudo-english report that summarizes the policy. 

5 

It should be appreciated that it is not necessary to run the compiler because 
the policy monitor component automatically compiles and installs policy from 
the policy specification file. 

10 Platform 

The policy generator 110 runs on a Windows NT or Unix machine, while the 
policy monitor 100 and the network monitor 127 run on Linux machine(s). It 
should be appreciated that these components can run equally well on other 
suitable operating systems. In addition to policy and network monitoring 
15 software, the following software components are also installed on the 
appropriate machines: 

• Microsoft Visual C++ 6.0; 
20 ♦ Sybase ASE 11.9.2; and 

• NT NDIS packet drivers and Windump 2.0. 

It should be appreciated that these components can run equally well on other 
25 compilers, databases, and packet monitoring systems. 
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Policy Files 

There are two file types that are used within the invention's environment, and 
are described below in Table B. 



Trtfe B 



File Type 


Suffix 


Description 


Policy wizard File 


.spw 


Intermediate file used by the policy wizard to store policy 
information between invocations. 


Policy monitor File 


.spm 


Output file generated by the policy wizartl and used as the 
policy input into the policy monitor. Contains a description 
of the policy in the policy language. 



The preferred embodiment of the invention incorporates a high level workflow 
method for developing policy, as follows: 

10 

1) Creating an initial policy using the policy generator tool; 

2) Uploading the policy file to a remote machine; 

15 3) During the initial policy development phase, running the network monitor to 
collect traffic, and the policy monitor to analyze traffic separately, as follows: 

a) Running the network monitor and specifying an output file of the 
collected traffic, and possibly specifying via parameter a limit to the number of 
20 packets captured, e.g. 50,000; 
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b) Running the policy monitor to analyze traffic collected by specifying the 
file containing the collected traffic; 

5 4) Examining the output of the policy monitor run by querying the database 
using the query tool; 

5) Modifying the policy as needed using the policy generator tool; and 

10 6) Repeating steps 2 through 5 until a comprehensive desired policy is 
defined. At this point the end user may start monitoring network traffic on a 
continuous basis, and using generated reports as input for further policy 
refinement. 

15 High Level Workflow Example 

The high level workflow described above can be illustrated further by 
understanding an example, as follows. System components of the invention 
are referenced using Fig. 1 . Screen Interactions are described with reference 
to the preferred embodiment of the invention. Other screen displays with 

20 similar function might equally well embody the invention. 

Referring to Fig. 2, an initial policy is generated (201). Often the initial policy 
is created from corporate network policy, in whatever form that may take, and 
a network topology diagram. For the sake of this example, it is assumed that 
25 the policy wizard 110 was used to generate an initial, simple policy 105. 
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Next, compliance of current network traffic to this initial policy is monitored 
(202). Such monitoring is achieved by collecting packet information off the 
network and running such data 115 against the initial policy 105 using the 
policy monitor 100. 

5 

Then the query tool 135 is used to data-mine output network event data from 
the database 104, using the mined data to check for traffic that is not 
consistent with the policy 105, and reporting the results (203). 

10 Once anomalies have been found, the next step is to work out where the 
problem lies. The problem could be network equipment is misconfigured and 
needs to be corrected (203); otherwise acceptable behavior is not covered 
currently by the policy specification file the file needs to be corrected (204); or, 
otherwise acceptable behavior is not covered currently by the corporate policy 

15 and the corporate policy needs to be corrected (205). In the case of this 
example, it is assumed that the policy specification 105 is incomplete and an 
end user needs to add a new rule to permit the observed traffic pattern. 

Generate a Policy Specification File From a Wizard Policy 

20 The end user starts the policy generator tool, or wizard 1 1 0, by double clicking 
on a policy wizard shortcut on the end user's desktop. In the preferred 
embodiment, a window such as depicted in Fig. 3 opens. 

In this example, the end user has opened a file, c:\spm\quickstart\null.spw, 
25 through the File->Open menu item 301 . This file contains a very simple policy 
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that defines a single policy domain defined by a 10.0.0.0/8 subnet mask. 
Rules within this policy deny essentially all traffic. 

The end user chooses to compile the policy, whereby the dialog box in Fig. 4 
5 opens. The end user presses the "Process Policy" button 401 and a file 
named null.spm in the output file exntry field 402 is generated and saved. 

Fig. 4b shows the dialog box in Fig. 4a with printed results from the compile 
process in a text window 403. 

10 

File Running Policy Monitor Over Canned Data 

The end user starts the policy monitor 100 by double clicking on a policy 
monitor shortcut on the desktop. In the preferred embodiment, a window such 
as depicted in Fig. 5 opens. 

15 

The end user ensures that the "Input Dump File" entry field 501 points to a 
data dump file, here qs.dmp, and that the "Policy" entry field 502 points to the 
null.spm (monitor) file that the end user generated above. The "Monitoring 
Poinf entry field 503 is derived from a policy domain name "Intranet" that is 
20 present in the null.spw (wizard) file. 

The end user ensures database connectivity information is set correctly. The 
ODBC entry field 504 with entry "sybase" points to a Sybase database 
running on a local machine. The usemame "policy" 505 with some password, 
25 shown as "******•' 506 have been preinstalled. 
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The end user presses the Run button 507 and the .dmp file is processed 
through the policy specification file 105 placing the output data into the 
database 104. 

5 Look at the Results Using Query Tool 

The end user starts the query tool 135 by double clicking on a query tool 
shortcut on the desktop. In the preferred embodiment, a window such as 
depicted in Fig. 6 opens. 

10 The end user presses a "Network Events" button 601 and the dialog box 
depicted in Fig. 7 appears. Fig. 7 is a dialog box that allows the end user to 
enter login information for the database 104. 

Here, the end user enters the same usemame and password as was used in 
15 policy monitor 100 and connects to a database 104 named Policy on 
localhost. 

When connected, the screen shown in Fig. 8 appears. Fig. 8 is a dialog box 
that allows the user to select which processed network data to view from 
20 database 104. The topmost entry in the "Execution Run" pull-down contains 
most recent data was added to the database 104. In this case it is current 
processing of the qs.dmp file. The end user presses the "Query" button and 
network event information for this run is retrieved from the database 104 and 
shown in as in Fig. 9. 

25 
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Fig. 9 shows a queried rule view dialog box according to the preferred 
embodiment of the invention. Fig. 9 shows that the null.spw policy has denied 
all traffic. The network events having disposition Udp„AccessJDenied 
represent DNS lookups from an internal host (10.5.63.143) to another internal 
5 host (10.5.63.6). It is assumed for this example that this is traffic conforming 
to policy, and therefore the end user adds a rule to the policy to permit this 
event. 

Add a New Rule Using The Wizard 

10 The end user returns to the policy wizard main window and presses the "Edit 
Rules" button which opens a dialog box as shown in Fig. 10a. Fig. 10a shows 
a dialog box for generating a new rule according to the invention. The end 
user selects the "Intranet" domain from the "Policy Domain" pull-down to add 
a rule for our Intranet domain. The end user types a rule name, such as 

15 IntemaLDns into the "Rule Name" field and presses the "New" button. The 
end user selects the communities and services to which this rule applies. For 
simplicity in this example, the end user wants to allow DNS from any internal 
nodes to any other internal nodes and therefore selects an Initiator community 
of hosts Insidejslodes, a service of DNS, and a Target community of hosts 

20 lnside_Nodes. The end user then presses the "Add Selected" button for each 
in turn to create a rule as shown in Fig. 10b, where Fig. 10b shows a dialog 
box for generating a new rule according to the preferred embodiment of the 
invention. 

25 Next the end user generates a new policy specification file and runs policy 

monitor. The end user returns to the query tool and presses the "Network 
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Events" button again to get a new rule view dialog box. The topmost 
"Execution Run" is now the output from the processing just completed. The 
end user presses the "Query" button and can now see that DNS traffic from 
10.5.63.143 to 10.5.63.6 is now conformant to the policy as shown in Fig. 10c, 
5 where Fig. 10c shows the communities of the policy specification. 

Detailed Description of Components 

The preferred embodiment of the invention incorporates the following 
components, detailed description of which follows below. 

10 

The Policy Generator Tool 
The preferred embodiment of the invention provides a policy generator tool, or 
simply policy generator, equally referred to as policy wizard, that provides a 
level of abstraction on top of the policy language, and which simplifies the 
15 process of creating an initial policy based on gross characteristics of a 
network at the IP level, such as policy domains, communities of hosts, 
servers, subnets, firewalls. 

The policy generator provides a novel mechanism for translating desired 
20 network security policy, such as corporate network security policy, into a 
policy specification file that can be interpreted and implemented by a policy 
monitor mechanism. 

Building a policy with the policy wizard involves: deciding on logical divisions 
25 within the network, i.e. policy domains, grouping network nodes into logical 
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communities, and expressing rules about which communities of hosts can 
provide what services to which communities of hosts. 

High Level View of Policy Generation 

5 The first step in building a basic policy is to define a high-level topology for the 
network. Not much detail is necessary. In the preferred embodiment of the 
invention, the network needs to be divided into bounded units called policy 
domains. In practice, the choice of a policy domain boundary is fairly obvious. 
Usually natural logical and physical boundaries in a network help define policy 
10 domain boundaries. For example, firewalls and routers with packet filters 
commonly denote the important boundaries. When defining a simple policy, it 
is reasonable to ignore switches, bridges, hubs, and routers that connect 
interior subnets. 

15 It is suggested that policy domains be as small as required by traffic 
monitoring limitations and as large as specification of rules allow. Rules are 
written about traffic visible in a policy domain. Traffic in a policy domain is 
logically considered to be visible anywhere within the policy domain even 
though networking elements, such as, for example, switches prevent such 

20 visibility in most networks. By writing rules about traffic as though it is visible 
anywhere within the policy domain, the same set of rules can be applied to 
network traffic anywhere within the policy domain. 

It has been found that if a policy domain is too small, rules need to be 
25 duplicated for each extraneous policy domain. If a policy domain is too large, 
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then the choice of a network traffic monitoring point can become overly 
constrained, or the ability to detect IP spoofing and rogue routers is lost. 

Identify the Policy Domains 

5 Fig. 11 shows a high-level view of an example network. An Intranet 1101 is 
connected to a DMZ 1102 through a firewall 1103. The DMZ 1102, in turn, 
connects through a router 1104 to the Internet 1105 and through a second 
router 1106 to an external corporate network 1107. In this example, an end 
user is only expected to be able to monitor traffic in the Intranet and DMZ, so 
10 these two entities are declared to be policy domains. Rules in the policy only 
apply to allowed traffic in the DMZ and Intranet. The corporate network and 
Internet are viewed only as communities of hosts visible from within the policy 
domains. 

15 It should be appreciated that the end user could choose to declare the 
Internet and Corporate network to be policy domains, but, by doing so, would 
only create unnecessary work because the end user does not intend to 
monitor traffic there. Any rules generated would thus never be used. 

20 Add Perimeter Elements 

In the preferred embodiment of the invention, the point of connection of a 
policy domain to the outside world is known as a perimeter element. For each 
perimeter element the set of nodes visible through it needs to be known and, 
for generating rules to detect IP spoofing and rogue routers, the MAC address 
25 of the perimeter element itself needs to be known. 
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As an example, if an end user could sit inside a policy domain and look out 
through boundaries, it is probable that the end user would see a filtered 
version of what is on the other side. Network address translation (NAT) can 
5 change the IP addresses seen though the boundary. For example, a proxying 
firewall may not let the end user see anything directly beyond a single IP 
address at the boundary. Filters may limit the view to only a few hosts when 
thousands are actually present. 

1 0 Define Communities 

In the preferred embodiment of the invention, communities consist of sets of 
IP addresses. They can be expressed as, for example, individual IP 
addresses, ranges of addresses, or subnet masks. Additionally, communities 
can be composed of other communities. It is often the case that a community 
15 of nodes involves all nodes in some existing set except for a node or two. 
Communities are defined in terms of included elements and excluded 
elements. 

Define Rules For Each Policy Domain 

20 In the preferred embodiment of the invention, rules defined for a policy 
domain describe allowed transactions. For example, if no rules are written, 
the policy specifies that everything at the IP level or above is denied, although 
this specification is not strictly true because typically auto-generated rules that 
apply to IP broadcast traffic and ICMP traffic within the policy domain exist. 

25 Rules create holes in this base layer that declares all traffic illegal. 
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Rules are defined in terms of initiator communities, target communities, and 
the services allowed. Services consist of a set of port numbers and indicators 
of whether TCP or UDP protocols are used. 

5 Using the Policy Generator 

The preferred embodiment of the invention provides a front end for the policy 
generator. It provides a user interface for entering and editing a simple policy. 
The front end reads and writes the current state of a policy from or to an 
intermediate file. The currently preferred extension for the intermediate file is 
10 .spw. When a policy has been specified to the satisfaction of the end user, it 
is written to an intermediate policy file for processing by the policy generator 
backend that generates a formal policy specification file compatible with the 
policy monitoring system. 

15 The front end allows the end user to edit policy domains, communities, 
services, and rules, to read and write the current policy from or to an 
intermediate file, and to process the intermediate policy file into the formal 
policy specification file. 

20 The preferred embodiment of the invention allows several instances of each 
editing process to be open simultaneously. The interaction is intended to feel 
very live. Data changed in one editing process should be reflected in the 
contents shown in other editing processes. For example, if a community is 
added in one community editing process, then it is immediately available for 

25 use in all editing processes. When building a policy, entities are first created, 

then filled in. From the time of creation they can be used throughout the 
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policy. Consequently, a community or policy domain does not need to be fully 
specified in order to be used. However, to prevent errors in backend 
processing, all entities should be complete before the intermediate policy file 
is submitted to the backend for policy specification file generation. 

5 

In the preferred embodiment, only one policy is under development at any 
time. The front end starts up containing a default policy that is empty except 
for some predefined default services. This policy can be used as a starting 
point or an existing policy can be read from a saved intermediate policy file. 

10 

It has been found that it is best to use simple names in developing a policy 
and to use a name that makes sense from a predetermined point of reference, 
not a fully qualified name that makes sense from any point of reference. For 
example, it is better to give a rule a short, descriptive name such as, 
15 w Allow_Outgoing_Mail" than to give the rule a long name such as, 
"Allow_MaiLFromJntranet_To_Outside_lntranet". 

For an in-depth understanding of the formal policy specification generated by 
the policy generator, or policy wizard, please refer to the section, 
20 Understanding the Wizard Generated Policy , below. 

Collecting Packet Data 

The preferred embodiment of the packet gathering component 128 is a 

program referred to as the harvester. It reads packets off the observed 

25 network 125 and writes them to either a packet capture file 126 or to a TCP 

socket that is connected to the policy monitor 100. 
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As an example, the harvester reads packets off the network when invoked as 
follows: 

5 harvester -i ethO -c 1 000 -dump qs.dmp 

In this example, 1000 packets are read from a network interface labeled 'ethO' 
and stored in file 'qs.dmp.' 

10 The harvester can also be configured to read packet data and convert it to 
event data suitable for policy monitor 100. As an example, the harvester may 
be invoked as follows: 

harvester -i ethO -c 1000 -enc qs.dme 

15 

In this example, 1000 packets are read off the network interface labeled 
*eth0\ converted to event data suitable for policy monitor 100, and stored in 
the file 'qs.dme 1 . 

20 The harvester can also be configured to read packet data, convert it to event 
data suitable for policy monitor 100, and stream such data directly to the 
policy monitor in real time. As an example, the harvester may be invoked as 
follows: 

25 harvester -I ethO -c 1000 -enc 1 0.5.63.6:333 



36 



WO 01/99349 PCT/US01/18669 

In this example, 1000 packets are read off the network interface labeled 
'eth0\ converted to event data suitable for policy monitor 100, and transmitted 
in a TCP network stream to port 333 on the machine with IP address 
10.5.63.6. This machine and TCP port may be configured so that the policy 
monitor 100 reads the data and processes it. 

It should be appreciated that the events are transmitted as they are 
processed, so that the policy monitor 100 is able to see events shortly after 
they occur on the observed network 125. 

In this mode of operation, the policy monitor 100 is also able to pass 
information about policy dispositions back to the harvester. The harvester can 
use this information to make processing of packets more efficient. For 
example, if the policy monitor 1 00 has determined that a given network event 
is acceptable according to the policy, the monitor can sometimes expedite its 
protocol processing by skipping packets until the network event terminates. 

Polipy Monitor 

The preferred embodiment of the invention provides a policy monitor 
component that provides a user interface, either graphical or command line, 
that allows the configuration of various options of the monitor, policy engine 
and logger. 

Monitor Configuration 

Monitor configuration allows the end user to configure the location of the input 

packet dump, policy to be used, and the specification of the monitoring point. 
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The Input dump file specifies the input file, in tcpdump format that is to be 
used. 

5 The Policy input specifies the .spm file that contains the policy specification to 
be used. 

The Monitoring Point is a specification of where the Input dump file was 
collected. This name is derived from policy domain names that are specified 
10 in the policy wizard. For example, if a packet dump was collected in a policy 
domain named "Intranet" then the Monitoring Point name 
INTRANET JVIONITOR should be used. 

Monitor Logging Options 

15 The monitor logging options allow the end user control of the location and the 
amount of data that gets written to the backend database. 

The Execution Run Comment field allows the entry of f reeform text that is 
added to the logs in the database to help identify this particular run of policy 
20 monitor. 

ODBC Name provides the name of the ODBC source to which output data is 
written. The DB Username and DB password are the end user's database 
login information. The Save Password allows the program to save the 
25 password in the clear so that it does not need to be entered the next time the 
program is run. 
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Output Options 

Output options allow the end user to specify whether the trace output from the 
monitor should be displayed in a console window (Output to console) or sent 
5 to a file {Output to file:). 

Advanced Options 

Advanced options allow more options to be set. In day to day operation, it is 
rare that such options need to be changed. 

10 

Advanced Monitor Configuration 

An Assert DLL parameter allows specification of the name of the DLL to be 
used to verify condition and credential assertions. Note that if this DLL does 
not match the version of the policy specified then this DLL is regenerated, 
15 overwriting the provided DLL. 

A Trace Options parameter allows the end user to provide configuration of 
runtime trace options. This option affects the amount of output generated by 
the monitor. For a more efficient operation, this field should be left blank. 

20 

A Certificate Dir argument points to a directory that contains trusted CA root 
certificates in DER encoded form. 

Advanced Packet Logging Options 

25 The packet logging options section allows the configuration of the trace 

options to be provided by the low level packet monitor. The various logging 
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options may be specified at a global level (by setting them for layer "-All-") or 
individually on a per-layer basis. Again it is to be noted that specifying logging 
options adversely affect the performance of the monitor. 

5 The Site Handle parameter specifies a name that is associated with the 
particular company or site that is being monitored. It is used to segment a 
table that is used for IP-address name resolution within the output database. 

Advanced Monitor Logging Options 

10 The Disable Logging checkbox disables the writing of all logging data to the 
database. If logging is enabled then the remaining checkboxes provide for 
the enabling or disabling of the logging of network events with the given final 
disposition code. For example, if Disable Logging is not selected and only 
Policy Error selected then the only network events that are logged to the 

15 database are those that resulted in a final disposition code of 
POLICY_ERROR. 

During normal operation information about all protocol events within a network 
event is logged, even those that occurred after a final disposition was 
20 reached. An Enable All Layer Logging parameter can control this feature. 
When set on, all protocol events are logged to the database. When not set 
only those protocol events that are processed before a disposition is reached 
are logged. 
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QueryTool 

The preferred embodiment of the invention provides a query tool to examine 
the data that was placed in the database. The preferred query tool allows the 
following functions to be performed: 

5 

• Examining network events, such as protocol events, that are contained 
within the execution runs in the database; 

• Examining IP Connectivity for execution runs in the database; 

10 

• Editing and making user defined SQL queries to the database; 

• Performing forward and reverse DNS lookups (using the current DNS 
configuration); 

15 

• Viewing policy monitoring run information from the database, and selecting 
a default run for further viewing; 

• Explicitly connecting to a specific database; and 

20 

• Turning on/off IP address to hostname resolution. 

Other Tools 

The preferred embodiment of the invention provides other tools discussed 
25 below. 
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Compiler 

In its simplest form the compiler needs just a single argument that is the input 
policy specification file. This form is often all that is needed while doing initial 
development of a policy. It should be appreciated that the compiler is rarely 
5 used in standalone form since its function, with the exception of the -r flag, is 
subsumed into the policy monitor component. 

Example Usage 

During initial development a command such as the following could be used 
10 while getting rid of syntactic and semantic errors from the policy under 
development: 

pmsCompiler.exe security.pms 

15 Once compiler errors are gone, the end user is ready to generate pieces that 
are used to run the policy monitor. For example, the end user can use the 
command line: 

pmsCompiler.exe -d verify security.pms 

20 

that compiles the security policy, and generates a verification DLL named 
"verify.dir. 

Compiler Options 

25 The following arguments in Table C may be provided to the example 
pmsCompiler.exe. 
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Table C 

pmsCompiler -? -r 

-c <cxx-f ile> -d <dll-file> 
5 <policy-file>* 

-c <cxx-f ile> 

Generate Credential and Condition assertion verification code to the named file. The 
suffix u .cxx" is appended to the name that is provided. This option is rarely used to allow 
1 0 the end user to look at the actual code that is used to verify assertions. 

-d <dll-file> 

Generate a DLL containing the assertion verification code to the named file. The suffix 
*\dir is appended to the name that is provided. If the -d flag is used without the -c flag 
15 then the source code is written to a temporary file. This option is often used to generate 

the assertion verification DLL. The alternative is to allow the runtime Policy Monitor to 
generate the DLL for itself. 

-r 

20 Generate a pseudo-english description of the policy to stdout. The output of this 
command is a useful starting point for a policy report to a customer. 

-? 

Display a usage string. 



25 



<policy-file> 

The required policy specification (".pms") file. 



-b <db-name> 
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Store information about the compiled policy in the named database, db-name is the 
name of a user data source that has been configured within Control Panels->ODBC. This 
argument is rarely used. The alternative is to allow the runtime Policy Monitor to write the 
policy to the database if needed. 

5 -o <output~file> 

Redirect compiler messages to stdout to the named output file. Rarely used 
-t <trace-opts> 

Enable debug tracing. For more specific details try providing the argument "-t ?". This 
option is rarely used because it only provides information to allow debugging of the 
10 compiler itself. 

-v 

Use VisualC++ to preprocess macros rather than the internal preprocessor. This 
overrides the -n option. This option is rarely used. 

15 -g 

Add debug trace code, /.©. printf statements, to the generated Credential and Condition 
, verification code. The generated code is compiled with symbol information (the C 
compiler -g flag). This option is rarely used. 

20 -n 

Do not run a preprocessor. C preprocessor macros such as #define and #include may be 
included within a policy file. This option specifies that the pre-compiler should not be run 
prior to actually compiling. This option Is rarely used. 

25 -z 

Output the dump output of the parsed policy. This output looks remarkably similar to the 
input file with the comments stripped and some component definitions reordered. 

Network Monitor 

30 The preferred embodiment provides a streams-based network monitor that 
can be run in a standalone mode independent of the policy monitor. In this 
way it can be used to provide a detailed, streams-based view of the network 
traffic, or a subset thereof. For example, run in standalone mode is desirable 

44 



WO 01/99349 



PCT/USOl/18669 



when a particular protocol is not supported natively by the policy monitor and 
an end user desires to see raw data to gain an understanding of what is going 
on. 

5 It should be appreciated that a convenient way of accessing such functionality 
is through the query tool. 

Example Usage 

The following invocation of the network monitor: 

10 

mon -ev2-l ALL=all C:\spm\quickstart\qs.dmp 

examines the qs.dmp file, producing extremely verbose output for event 2 
only. 

15 

Table D provides a list of network monitor options according to the invention. 

Table 0 

Monitor Options 
20 mon [-log LAYER[=[-]optlon1 ,[-]optSon2...]]* 

[-n npkt] [-skip pkt] [-until endpkt] 
[-ev eventID] [-untilev eventid] [-justev eventid] 
[-noclients] dump_f ile 
-log 

25 -n npkt 

Only process the first npkt packets from the input data, 
-skip pkt 

Skip pkt packets before beginning to process the Input data. 
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-until endpkt 

Only process data through the packet number provided Is reached 
-ev eventID 

Only process the data starting at the given eventiD. 
5 -untilev eventid 

Only process the data through eventid. Note that to find the end of eventid, events 
with ids greater than eventid may be processed, 
-justev eventid 

Only process the data for eventid. Note that to find the end of eventid, events with 
10 ids greater than eventid may be processed. This option is the equivalent of -ev 

eventid -untilev eventid. 
-noclients 

Do not generate any output for higher level protocols such as HTTP, FTP, etc. 
dump_file 

1 5 The dump file, in tcpdump/windump format, that contains the input data. 

Understanding the Wizard Generated Policy 

Using the Policy Generation Wizard, a user specifies a network security policy 
in terms of the network services provided by certain hosts to other hosts in the 

20 network. When such policy is processed, the wizard generates a formal and 
more detailed description of the network security policy using the policy 
language. The policy language specification may then be used to analyze 
network traffic using the policy monitor tool. The results of this analysis can 
be studied using the query tool. An exemplary policy language is taught in A 

25 Declarative Language for Specifying a Security Policy, patent application 
number 09/479,781 (1/7/2000). 
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Understanding the output of the preferred query tool requires understanding 
how the preferred wizard translates the high-level view of security policy it 
presents to its users into a set of policy language objects such as rules, 
credentials and dispositions. 

5 

Understanding the policy generation process involves the following: 

■ Understanding the predefined rules, credentials and dispositions; 
10 ■ Understanding the implicit rules and credentials; and 

■ Understanding the explicit rules and credentials. 

Predefined Rules, Credentials and Dispositions 

15 Every policy generated by the wizard includes a set of predefined default rules 
for handling protocol events that do not conform to the user-defined policy i.e. 
rules that deny access, as well as rules for handling common network events 
not covered by the user policy. These rules and their dispositions are shown 
in Table E and Table F, and further discussed below. 

20 



Table E 


Rule 


Protocol - Action 


Disposition 


ip_Deny 


IP -all 


lp_Access_Denied 


lcmp_Deny 


ICMP-all 


lcmp_Access_Denied 


Udp^Deny 


UDP-all 


Udp_Access_Denied 
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Tcp^Deny TCP - all Tcp„Access_Denied 

Http_Deny HTTP - all Http__Access_Denied 

Ftp_Deny FTP - all Ftp„Access JDenied 

SsLOeny SSL - all Ssl_Access_Denied 

Ssh_Deny SSH - all Ssh_Access_Denied 



Table F shows the default rules for all the protocols supported by the policy 
monitor. The policy engine selects these rules when no other rule can be 
found that is satisfied by the protocol event. 



Table F 



Rule 



lpJ)eny__PureJp 
Tcp_Mlssed_Connections 
FtpJgnore_Data_Connectio 
ns 



Protocol - Action 



Disposition 



IP - PROTOCOLJJNKNOWN Deny_Pure_lp 

TCP - MISSED_CONNECT Warn_Missed_Tcp_Connect 

FTP - DATA^_OPEN ok 



Table G below shows rules that cover protocol events not addressed by the 
10 wizard's user interface. These are well understood events that can be 
separated from those handled by the default rules. lp_Deny_Pure_lp is 
assigned to IP associations whose payload is not one of the three well-known 
IP-based protocols (ICMP, UDP and TCP). Tcp„Missed_Connections is 
assigned to network events where the establishment of the TCP connection 
15 was not witnessed by the policy monitor. FtpJgnore_Data_Connection$ is 
assigned to all FTP data connections which, from a security policy monitoring 
perspective, can be safely ignored. It is noted that the preferred policy wizard 
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generates other rules to deal with common protocol events as discussed 
below. 



Table G shows the predefined dispositions used by all the rules in the 
5 generated policy. Associated with each disposition are its disposition code 
and severity, which may be used in the query tool to filter network events. 



Table G 



Disposition Disposition Code Disposition Severity 



ok 


OK 




None 


policy-error 


POLICY_ERROR 


CRITICAL 


Ip^AccessJDenied 


ACCESS. 


.DENIED 


HIGH 


Deny^PureJp 


ACCESS. 


.DENIED 


HIGH 


Monitor^Broadcasts 


OK 




MONITOR 


Icmp_Access_Denied 


ACCESS. 


.DENIED 


HIGH 


Monitorjcmp 


OK 




MONITOR 


Udp_Access_Denied 


ACCESS. 


.DENIED 


HIGH 


Tcp_Access_Denled 


ACCESS. 


.DENIED 


HIGH 


Warn_Mlssed^Tcp_Connect 


OK 




WARNING 


Ftp_Access_Dented 


ACCESS. 


.DENIED 


HIGH 


Http_Access__Denied 


ACCESS. 


JDENIED 


HIGH 


SsI_Access_Denied 


ACCESS. 


.DENIED 


HIGH 


Ssh_Access_Denied 


ACCESS. 


DENIED 


HIGH 



10 



It should be noted that ok and policy-error are actually built-in dispositions in 

the policy language. If policy-error \s encountered it indicates an error in the 

processing of either the policy or the network traffic data by the policy monitor. 
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The meaning of the other dispositions is explained later in this document in 
the context of the rules in which they are used. 

Finally, the wizard includes a set of predefined credentials that are combined 
5 with dynamically generated credentials and used in implicitly generated rules: 

MulticasLAddresses - a set of commonly used IP multicast addresses; 

LocaLBroadcast__Address - the IP address used for non-directed local 

10 broadcasts (255.255.255.255); and 

ZeroJp__Address - a zero-valued IP address (0.0.0.0), commonly used 

by BOOTP clients; 

15 It is noted that the double underscore prefix in these credential names is used 
to ensure that there aren't any name conflicts with credentials generated to 
represent user-defined communities and services. 

Explicit Rules and Credentials 

20 Every community defined by the user results in a credential of the same 
name. Because the scope of a community name is that of the entire policy 
specification, the resulting credential names need not be massaged to ensure 
uniqueness. 

25 Service names are also global in scope. Because services and communities 

share the same name space, every service defined in the policy results in a 
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credential whose name is constructed by prefixing the user-supplied service 
name with the underscore character. Thus, for example, the Smb service is 
represented by a credential named _Smb. 

5 Rule names, on the other hand, are only unique within the scope of a policy 
domain. Furthermore, if a user-defined rule addresses a service that is both a 
UDP and a TCP service, the wizard generates two rules, one for the UDP 
protocol and another for the TCP protocol. Thus, a rule name is constructed 
by prefixing the user-supplied name with the protocol name (Udp_ or TcpJ) 
10 and the policy domain name. 

For example, if the user defines a rule titled Smb_Services within a policy 
domain named Intranet, the wizard generates two rules, 
UdpJntranet_Smb_SeMces and TcpJntranet„Smb_Sewices, for the UDP 
15 and TCP protocols respectively. 

User-defined rules may also result in the generation of additional credentials. 
When defining a rule, the user provides the following information: 

20 ■ Zero, one, or more initiator communities; 

■ Zero, one, or more services; and 

■ Zero, one, or more target communities. 

25 
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If more than one initiator community are specified, the wizard generates a 
credential that combines these communities into a union. The credential 
name is constructed by appending the word JnitiatorXo the user-supplied rule 
name, prefixed by the policy domain name. Using the example above, the 
5 wizard would create a credential named lntranet_Smb__ServicesJnitiator. 

Likewise, if more than one target communities are specified, the wizard 
creates a credential representing their union and names it by appending the 
word ^Target to the policy domain and rule names, e.g. 
1 0 lntraneLSmb„Services_ Target). 

However, if one or more services are specified they are combined with the 
target credentials according to the service type. For example, the Smb 
service (for the SMB protocol suite) and its like-named credential include ports 

15 that are used for both TCP and UDP. Thus, for the Smb_Services rule used 
above, the wizard would generate the following additional credentials: 
Udp_lntranet_Smb_Services„ Target and 
Tcp_lntranet_Smb_Services_Target. These credentials combine 
lntranet_Smb_Services_Target (or a single target community) with the _Smb 

20 credential and constitute the actual target credentials used in 
Udp_lntranet_Smb_Services and TcpJntranet_Smb_Services respectively. It 
should be noted that, in many cases, the set of UDP and TCP services 
referenced in a rule have little, if any overlap. 
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If the end user does not specify any services the wizard uses the 
lntranet_Srnb_Services_Target credential (or a single target community 
credential) to identify the target principal. 

5 Implicit Rules and Credentials 

For each policy domain within the policy specification, the wizard 
automatically generates a set of rules and credentials that define the valid IP- 
level traffic seen at the monitoring point within the domain. In addition, an 
ICMP rule is generated that handles all intradomain ICMP traffic, as well as a 
10 credential for the monitoring point in that domain. 

The monitoring point credential is based on an agent descriptor string 
manufactured by the wizard. The agent descriptor is constructed by 
converting the policy domain name to uppercase and appending to it the word 
15 _MONITOR. Thus, for example, a policy domain named Intranet is assigned 
the agent descriptor: 

INTRANETJMONITOR. 

20 Note that this is the agent descriptor to be used in the policy monitor when 
analyzing data collected at this monitoring point. 

The monitoring point credential itself is named by appending the word 
_Monitors to the policy domain's name. In the example above, the credential 
25 is named lntranet_Monitors. 
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The wizard segregates all intradomain ICMP traffic (common on an enterprise 
network) by use of a rule that assigns it the disposition Monitorjcmp. The 
rule is named by combining the protocol name with the domain name using 
the word ^Within. For example, in the Intranet policy domain the rule is 
5 named lcmp_WithinJntranet 

IP traffic is described by a set of rules that systematically enumerate all valid 
IP-level traffic within the policy domain, between hosts in the policy domain 
and external hosts, and between external hosts through the policy domain 
10 (when more than one perimeter element is present). Most of these rules 
provisionally allow IP traffic, letting the subsequent protocol layers (ICMP, 
UDP, TCP, etc.) determine if the traffic is indeed allowed either by a user- 
defined (explicit) rule or by a predefined rule. 



15 The first IP rule provisionally allows all intradomain IP traffic. It is named by 
combining the protocol name with the domain name using the word ^Within 
(e.g., Ip^WithinJntranet). In the absence of a higher-level protocol within an 
intradomain IP association, the rule assigns the network event a disposition of 
Deny_Pure_lp, i.e. its final outcome. 

20 

The intradomain IP rule uses the policy domain's defining community as its 
target principal. However, it generates another credential to be used as the 
initiator. This credential combines the defining community with the predefined 

credential for zero-valued IP addresses ( Zero_lp_Address). The generated 

25 credential is named by appending the word ^Initiator to the generated rule 
name, e.g. Ip^WithinJntranetJnitiator. 
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Another intradornain IP rule is used to segregate typical broadcast and 
multicast traffic within an enterprise network. It is named by combining the 
protocol name with the domain name using the words ^Broadcasts^Within, 
5 e.g. lp_Broadcasts_WithinJntranet. Its initiator principal is the same as that 
used for the general intradornain traffic , e.g. Ip^WithinJntranetJnitiator. Its 
target is a new credential constructed by combining the predefined credentials 

MuIticast_Addresses and _LocaLBroadca$t_Addre$$ with the directed 

broadcast addresses for all the subnets within the policy domain's defining 
10 community. The new credential is named by appending the word _Target to 
the rule name e.g. lp_Broadcasts_WithinJntranet_Target 

The intradornain broadcast and multicast traffic is assigned the disposition 
Monitor_Broadcasts. 

Traffic between hosts in the policy domain and external hosts is described by 
a set of rules whose complexity depends on how much information the user 
supplied about the topology of the network. Specifically, it depends on how 
many perimeter elements were specified and on whether or not the interface 
addresses, i.e. MAC addresses, of the perimeter elements are included in the 
policy specification. 

If there are external communities associated with at least one perimeter 

element for which the interface address is not known, the wizard generates a 

25 credential combining all such communities in a single union unless there is 

only one such community, in which case its credential already exists. This 
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credential is named by combining the policy domain name with the string 
^ExternaLCommunities, e.g. lntranet_ExternaljCommunities. 

The wizard then generates two rules defining the traffic between hosts internal 
5 to the policy domain and these external communities. The wizard names 
these rules by combining the protocol name with the domain name and the 
string JTo_ExternaLCommunities or _ExternaLCommunitie$_To t depending 
on the direction of the IP traffic, e.g. lpJntranet„To_ExternaLCommunities 
for outbound traffic and lp_Extemal_Communltie$_ToJntranet for inbound 
10 traffic. 

The credentials used alternately as the initiator and target principals for these 
rules are the policy domain's defining community and the aforementioned 
credential for the external communities. The rules provisionally allow the IP 
15 traffic to flow, subject to other rules for higher level protocols. In the absence 
of a higher-level protocol within the network event, the rule assigns it a 
disposition of Deny_PureJp, /.a its final outcome. 

External communities visible through one or more perimeter elements whose 
20 interface addresses are known, are handled by a separate set of rules, two 
per perimeter element. For each perimeter element, the wizard starts by 
creating a credential that combines one or more credentials for one or more 
external communities visible through it with the perimeter element's interface 
address. Such credential is named by combining the domain name with the 
25 perimeter element name and the string ^Communities. For example, external 
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communities visible through a perimeter element named Firewall are 
described by a credential named lntranet_Firewall_Communities. 

The wizard then generates two rules defining the traffic between hosts internal 
5 to the policy domain and the external communities visible through this 
perimeter element. The wizard names these rules by combining the protocol 
name, the domain name, the perimeter element name and the word _7b, e.g. 
Ipjntranet_ ToJntraneLFirewall for outbound traffic and 
IpJntranet^FirewalLToJntranet tor inbound traffic. 

10 

The credentials used alternately as the initiator and target principals for these 
rules are the policy domain's defining community and the aforementioned 
credential for the external communities. The rules provisionally allow the IP 
traffic to flow, subject to other rules for higher level protocols. In the absence 
15 of a higher-level protocol within the network event, the rule assigns it a 
disposition of Deny_Pure_lp, i.e. its final outcome. 

Finally, if there is more than one perimeter element associated with the policy 
domain, the wizard generates rule-pairs that describe the traffic between 

20 external communities visible through specific perimeter elements as well as 
external communities visible through any perimeter element, i.e. those without 
associated interface addresses. The rules are named by combining the 
names of each pair of perimeter elements with the protocol name, the policy 
domain name and with the word JTo, in the case of addressable perimeter 

25 elements, or with the string ^ExtemaLCommunities, for all other external 

communities. An additional rule is generated to cover traffic between external 
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communities not associated with an addressable perimeter element and is 
named by combining the protocol name with the domain name and the string 
__Between_ExternaLCommunities. 

5 Thus, if the Intranet domain used as an example in this section were to have a 
second (addressable) perimeter element named Router and a third non- 
addressable perimeter element (whose name is unimportant), the wizard 
would generate the following rules to cover all traffic amongst their respective 
external communities: 

10 

• IpJntraneLFirewalL ToJntraneLRouter 

• lpJntranet_RouterJToJntranet_Firewall 

1 5 • IpJntraneLFirewalL To^ExternaLCommunltles 

• lp_ExtemaLCommunities__ToJntranet_Fir&wall 

• lpJntraneLRouter_To_ExtemaLCommunities 

20 

• lp^ExternaLCommunitias_ToJntranet_Router 

• lpJntranet_Between_Extemal_Communities 

25 Table H and Table I summarize all the implicit rules and credentials generated 

for the example policy domain Intranet The policy domain includes two 
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perimeter elements with a specified interface address (Firewall and Routef) 
and a third non-addressable perimeter element. 



Credential 



IntraneLMonitors 
lp_WfthlnJntraneUnlt!ator 
lp_Broadcasts_ Wlthlnjntranet 
JTarget 

lntranet_External_Communities 
lntranet_FirewalljCommunities 
lntranet_Router__Communitie$ 



Tflble H 



Comment 



Uses agent descriptor INTRANET JVIONITOR 
Defining community plus zero-valued IP address 
Combines standard multicast addresses with local 
broadcast and directed broadcast addresses 
Combines all external communities not associated with 
addressable perimeter elements 

Combines all external communities visible through the 
Firewall perimeter element 

Combines all external communities visible through the 
Router perimeter element 



Table 



Rule 


Credentials 


Disposition 




(I - Initiator 


(1 - Immediate 




T- Target) 


F - Final) 


lp„Wfth!nJntranet 


1: Ip^WfthinJntranetJnitiator 


1: continue 




T: Intranet 


F: DenyJPure_\p 


lp_Broadcasts„WitbinJntranet 


1: lp_Within_lntranetJnitiator 


1: 




T: 


MonitorJBroadcast 




lp_Broadcasts_ Within_lntranet_ Ta 


s 




rget 




lcmp__Within_lntranet 


1: none (ignore) 


1: Monitor Jcmp 




T: none (ignore) 






Note: uses IpJNithinJntranet as 
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Rule 


Credentials 


Disposition 




(1 - Initiator 


(1 


- Immediate 




7- Target) 


F 


- F/na/J 




orereaufsite 






lpJntranet_To_External_Communit 


1: Intranet 


1 • 


pnntln ma 


ies 


T: Intranet External Communities 


F' 
i . 


L/eny_ ~ure_ip 


Id External Communities To Intra 


1* Intra n&t Fvtarn al r^nmmi in Itiac 
i. tint at tai^cZAitfi il&i_KsUifJfnuntllGS 


i • 

i : 


continue 


net 


1 * tt tttcff IGt 


r-. 

r. 


^nyJPureJip 


Id Intranet To Intranet Firewall 

'f*j*» **f » w l_ 1 \J It III CTIiOi III C7tVCf/f 




1 : 


continue 




T* trttfancit Ft rat A/a H r*r\mmitniti£*c 


c» 

r: 


Deny_Pure_lp 


Id Intranet Firewall To tntrstnat 


i. inir&neT^rirewau^KsommunitiQs 


1 : 


continue 




i . inxranex 


F: 


DenyJPureJp 


Irj Intran&t Trs Intra nat Or>ntr%r 


i. intranet 


1 : 


continue 




i . intranei_Houter_jJommunities 


F: 


DenyJPureJp 


In intra no ¥ Dr% t it t% rTs> intra rta # 


I. intranet_Houter_Communities 


1 : 


continue 




i . iniranei 


F: 


DenyJPureJp 


In Intra n at raw/all 7Vi Intranet D 


I. intranet_Ftrewall_Communities 


1 : 


continue 


a ii far 


i . inxranex_Houter_Communmes 


F: 


DenyJPureJp 


/o lntt"f}nt*t /?i*w tt&r T/*» Intranet 

ifj~—fi m ana .nt/utt?/ # o intronGlj 


i. inxranex__Houter^communitie$ 


1 : 


continue 


Firewall 


i . finianGi^rtrewasi n \JommUnWes 


r: 


DenyJPureJp 


Id Intranet Fir&wall 7V> Fvt&mal f 


i. iniranex__rirewau^{sOmm unities 


1 : 


continue 


V* If II fWf f/4fC7d 


i . inxranex_cxxema\_uommuf)nles 


F: 


Deny^PureJIp 


frt Fvt&mai f*V*w>i»»» tin If/a e Ta l»%+wa 

ifj^tmA, tern cf f_ won uiiu nines j i Ojinxra 


1. mtranet^External^Communlties 


■ _ 
1 : 


continue 


netJFirewall 


T: Intranet^FirewalLCommunlties 


F: 


Dew Pure to 


lpJntranet^RouterJTo_ExternaljO 


1: lntranet_Router_Communitles 


1: 


continue 


ommunltles 


T: IntraneLExtemaLCommunities 


F: 


Deny_Pure_lp 


lp_ExternaLCommunities_ Tojntra 


1: lntranet_ExtemaLCommunities 


I: 


continue 


net^Router 


T: lntranet_Router__Communities 


F: 


DenyJPureJip 


lp_lntranetjBetween_External_Co 


1: lntranet„ExternaLCommunities 


1: 


continue 


immunities 


T: lntranet__Extemal_Communities 


F: 


DenyJPureJip 
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Logging and Reporting Modules 

The preferred embodiment of the invention provides logging and reporting 
modules, as described herein with reference to Fig. 1 a. As the policy engine 
module 102 reaches dispositions on network events, it passes the network 
5 event object to the logging module 1 03. 

The preferred embodiment of the invention also provides an alarm script 155. 
As the policy engine module 102 reaches dispositions on network events of a 
certain disposition severity, for example, CRITICAL or HIGH, the alarm script 
10 is invoked to provide expedited alerting of the disposition. 



The following algorithm is used to enter the data into the database 104. 



♦ During initialization of the logging module 103, the database 104 is tested 
15 to see if it contains a policy that matches the MD5 hash of the policy 105 
currently being used by the policy engine 102. If no such policy is found 
then the policy details are added to the database 104; 



• with each network event passed to the logging module 103, if logging of 
20 network events is enabled, then: 

• if the final disposition of the network event matches one of the list of 
dispositions that is to be logged, then: 

25 • add the network event to the buffer of network events, 

flushing the buffer to the database 1 04 if it is full; 
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• loop through each of the protocol events contained in the 
network event; 

5 • if the initiator and responder principals have not been 

already added to the database 104 then do so, 
caching the database keys for later use; and 

• add the protocol event to the buffer of network events, 
1 0 flushing the buffer to the database 1 04 if it is full. 

On a periodic basis report statistics 161 are sent across a secure channel to a 
secure, customer accessible server 162. The preferred embodiment of the 
invention uses the following algorithm. 

15 

• A report script 160 described is used to generate a report 161 for the 
configured or predetermined time period. An example of a list of preferred 
acquired or calculated statistics or intermediate steps is contained in Table 
J below; 

20 

• The report 161 is then packaged using the tar command and PGP to 
encrypt the resulting file using the public key of a recipient email account; 
and 

25 • This encrypted file is then emailed to the recipient email account. 
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It should be appreciated that an equally preferred embodiment performs name 
resolution on packet data after the packet data has been collected, rather than 
concurrent with collecting the packet data. An advantage to such name 
resolution technique is that name resolution after collection is removed from 
5 real-time processing, thereby rendering name resolution more efficient. 

On the receiving secure server 162 the following algorithm is invoked on the 
received email message. 

10 • PGP is used to decrypt the received encrypted tar file; 

• Tar is used to extract the report data; 

• The report data is then processed to link the report into the reporting 
15 website 164 for the client; and 

• Any supplied protocol event data is then stored in a reporting database 
165. 

20 Upon accessing the reporting website 164 the client is able to peruse the 
reports that have been generated, access the protocol event data stored in 
the database 1 65 via a cgi script. 

Table J 

25 ♦ Generate network events in subsidiary web files, based on execution run; 

• Generate network events table, 

63 



WO 01/99349 



PCT/US01/18669 



• Generate table for URL's and status codes; 

• Find events of interest; 

• Check for all execution runs being in sequence; 

• Give best optimization for queries; 

5 • Compute number of events and number of exceptions; 

• Apply definitions of log severity and disposition code in order of criticality; 

• Apply query to several execution runs at a time, collect results; 

• Select key disposition and key policy rule first, to be able to find distinct 
disposition and policy rule; 

10 • Determine sort order for disposition and policy rule table; and 

• Generate a list of dispositions in the selected events, counting how many events 
were generated by each. 



Automated Ge neration of an English Language Representation of a Formal 
15 Network Security Policy Specification 

The preferred embodiment of the invention uses a formal specification of 
network security policy that is to be enforced on a network. This specification 
provides a precise, compact description of network security policy. However, 
it is difficult for a layperson to understand. In order to allow comprehension of 
20 the policy by non-technical staff within a user's organization the parser 
module (Fig. 1 150) is used to generate an English language description of 
the policy. This description is simple enough to be understood, yet captures 
the salient details of the policy. It will be appreciated that the invention 
generated a representation in a human readable language, such as english, 
25 those skilled in the art will recognize that the invention may generate 
representations in any human readable language. 
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The preferred embodiment of the invention provides the following algorithm 
for generating the English language representation. The algorithm comprises 
the following: 

5 • Loading the policy into the parser from its text representation; and 

• Looping through all supported protocols, from the highest level protocols to 
the lowest; 

10 • Sorting the rules for this protocol into ranked order; and 

• Looping through these rules from the highest ranking to the lowest; 

• Generating a text description of the rule using the algorithm below. 
15 If an HTML flag has been set then format the text into a HTML 

table; and 

• Append this description to a collection of descriptions already 
generated. 

20 

The preferred embodiment of the invention provides the following rule 

algorithm to generate an English language representation of a single policy 

language rule. The algorithm is described with reference to Fig. 12. The 

algorithm outputs the name of the rule at hand (2001). It then proceeds to 

25 output the agent's name (2002), where the agent is the subject network 

monitor(s) to which the policy applies. The algorithm then loops through all 
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protocol and action combinations (2003). If the action is to be ignored (2004), 
then the rule applies to the whole protocol (2005). Otherwise, the rule applies 
to certain actions only (2014). The algorithm then looks at the immediate 
outcome for the rule (2006). The algorithm then outputs the corresponding 
5 directive for the outcome (2007). If any conditions exist on the disposition, 
then the algorithm outputs the conditions (2008). The algorithm looks at the 
final outcome (201 1), then outputs the corresponding final outcome of the rule 
(2012). If any conditions exist on the disposition, then the algorithm outputs 
the conditions (2013). If the rule applies to a particular initiator or target, then 
10 the algorithm outputs the initiator or target name (2009). Otherwise, the 
algorithm outputs a general inclusive name, such as, for example, "anyone." 
The algorithm then checks for prerequisites (2010). If any are discovered, the 
algorithm then outputs such prerequisites. 



15 For an example of the rule algorithm discussed above, Table K below shows 
code to the example implementation. 

T abl e K 

if(lsBulltln()) 
20 return; 

Bool processedlmmedlate = false; 
Bool ImmedlateDefauHContlnue = false; 
Bool capitalizes true; 
25 string str; 

string protoool; 

// output the table row start 

if (html) str » w \n<tr><p>"; else str = "NnVi"; 

• 30 

// output the rule name 
If (html) 

str += VTD WIDTH=A"1 0%V VAUGN==\TOPVxB>« + getNlame() + "<a name = V" + getName() + 
w \ t ></axB><fTD> M ; 
35 else 
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str += -Rule ■ + getName() + B : 

// output the agent name 
string agentName; 
5 if (getAgent()==0) 

agentName = "AN Monitors* 1 ; 
else 

agentName = getAgent()->getName(); 

10 if (html) 

str += "<TD WIDTH=V5%Y' VAI_IGN==VTOP\V + agentName + M </TD> U ; 

// start the cell for the description 
If (html) 

15 str += '<TD WIDTH^Y'SSyoV 1 VAUGNM'TOPVV; 

// loop through the protocol and action combinations 
Bool first = true; 

for (PrsUnion::consUterator to = _protocol->begln(); 
tO !*=_protocol->end(); 
tO++) 

{ 

for (PrsUnion;;consUteratort2 =_action->beginO; 
t2l- jaction->end(); 
t2++) 

{ 

if (first) 

first = false; 
else 
protocol += 



20 



25 



30 



// if the action Is Ignore then It applies to the whole protocol 

if ((*t2)->getStrlngRepresentation() 1= PrsConst::META_IGNORE) 

o,- P 1 * 0 * 000 ' += (*tO)->getStringRepresentation() + + rt2)->getStrtngRepresentatfon() + " w ; 

oo else 

protocol += (HO)->getStringRepresentation() + - 

} 

} 

40 // look at the outcome to figure what we do with this traffic 

// Is there an Immediate clause 
if (Jmmedlate 1= 0) 
{ 

// output text based on the code 
string code - Jmmedlate->getDefaultO->getCode(); 
If (code «= PrsConst::DISPCODE_OK) 
{ 

capitalize ? str += "Allow " : str "allow "; 
capitalize = false; 
} 

else if (code = PrsConst::DISPCODE_CONTiNUE) 
{ 

If Lflna!->getDefault{)->getCodeO = PrsConst::DISPCODE_OK) 
5$ capitalize ? str += "Provisionally allow ■ : str += "provisionally allow 

else if (_finaI->getDefault()->getCode() = "POLICY_ERROR n ) 

; // say nothing... this Is the default 
else 
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capitalize ? str 4-= "Provisionally deny ■ : str += "provisionally deny 
ImmedlateDefaultContinue = true; 

} 

5 else 

{ 

capitalize ? str += "Deny * : str += "deny 
capitalize « false; 

10 str -h= protocol; 

If (Ummedlate->getGuardsO) l= 0 && CJmmedlate->getGuards()->slzeO i= 0)) /* KGS && 
limmedlateDefaultContlnue V 

15 if (Jmmedate->getGuardsO->ske() = 1) 

str+- Vrth condition ("; 
else 

str += "with conditions ("; 
first b true; 

20 for (etd::vector<PrsGuardedDlsposltlon*>;:consUterator cond « Jmmediate->getGuardsO- 

>beglnO; 

cond 1= Jmmediate->getGuards()->endO; 
cond++) 

25 if (first) 

first = false; 
else 

str +=','; 
If (html) str +='<!>"; 
30 str += (*cond)->getGuard()->getName(); 

If (html) str 4= V/l>"; 

} 

str+«"), 

35 processedlmmedlate = true; 

) 

// Is there a final clause 
ifLfinal 1=0) 
40 { 

If (Iprocessedlmmedlate) 
{ 

// output text based on the code 

string code =_final->getDefaultO->g9tCodeO; 
45 |f (code = PrsConst::DISPCODE_OK) 

( 

capitalize ? str += 'Provisionally allow ■ : str += Vrovlslonally allow "; 
capitalize = false; 

} 

else if (code = "POUCY_ERROR ,, ) 
; // say nothing... this Is the default 
else 
{ 

capitalize ? str +« 'Provisionally deny " : str += "provisionally deny 
55 capitalize = false; 

) 

str +a protocol; 
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If ((_final->getGuards()) 1= 0 && (_finat->getGaards()->sl2e0 1= 0)) 
{ 

if (_final->getGuards()->size() = 1) 

str+= "with condition ("; 
5 else 

str += "with conditions {'; 
Bool first = true; 

for (std::vector<PrsGuardedDisposltion*>::consLHerator cond = Jmmedlate->getGuards()- 

>begln(); 

10 cond l= Jmmediate->getGuards()->end(); 

cond++) 

{ 

if (first) 

first « false; 
1 5 else 

str+=", «; 
If (html) str +="<!>"; 
str += (*cond)->getGuard()->getNameO; 
if (html) str4.= -</l> B ; 

20 ) 

str "; 

) 

} 

else 

25 { 

// output text based on the code 

string code = _final->getDefault()->getCode(); 

M (limmedlateDefaultContinue) 

{ 

30 W (code = PrsConst::DlSPCODE_OK) 

str += "but provisionally allow 
else If (code = "POUCY^ERROR'*) 

; // say nothing.., this is the default 
else 

35 str += "but provisionally deny 

} 

If ((Jinal->getGuards()) != 0 && Lfinal->getGuards()->slze() != 0)) 
{ 

str += "with conditions ( n ; 
40 Bool first = true; 

for (std::vector<PrsGuardedDlsposItlon*>::consUlterator cond = Jrnrnedlaie->getGuards()- 

>beglnO; 

cond \s Jmmediate->getGuards()->endO; 
cond+~i-) 

.45 { 

if (first) 

first = false; 
else 

str += \"; 

50 If (html) str 4^ "<l>"; 

str +« (*cond)->getGuard()->getName(); 
Iff (html) slr+= •</!>■; 

} 

str +=")»"; 

55 ) 
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if (html) 
str += "from <l> 0 

+ (Jn!tlator->getCredential() ? Jnltiator->getCr0dentlal()">getName() : "anyone") 
+ "</i> to <l> n 

5 + (Jarget->getCredentlal() ? Jarget->getCredentlal()->getName() : "anyone") 

+ '</l> M ; 

else 

str -fcli-oro* 

+ {Jnitlator->getCredentlal() ? Jnltjator->getCredemial()->getName() ^anyone") 
10 +Mo M 

+ ( Jarget->getCredentlal() ? Jarget->getCredentlal()->getName() : "anyone"); 

If (getPrerequislte()l=0) 
{ 

1 5 str += " i provided that 

Bool first = true; 

for (vector<const PreRule*>;:consUterator t3 = _prerequlslte->begln(); 
t3 1= _prerequlsite->end(); 
t3++) 

20 { 

if (first) 

first = false; 
else 

str += ■ or "; 
25 if (html) 

str += "<lxa hrefo\*r + (M3)->getName() + T>" + (*t3).>getNameO + *</a><A>*\ 
else 

str += ( # t3)->getName(); 

) 

30 str += " is true.": 

} 

// start the cell for the description 
- if (html) 

35 str += "</TD></TR>"; 

else 

str 4= ■ (Agent " 4- agentName + V: 
40 ostm « stnc_8tr(); 

For an example of an output file generated by the main algorithm discussed 
above, Table L shows the example of the output in table format. For an 
45 example of a policy specification file that can be used as input into the main 
algorithm discussed above, refer to Table P below. 



Table i 
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Rules for prot oc ol HT TP 



Http Blocked Service Violation 


All 

/mi 

Monitors 


Deny HTTP from anyone to anyone, 
provided that Tcp Blocked Gap/fopa ic 
true. 


Http_Deny 


All 

Monitors 


Deny HTTP from anyone to anyone 


Rules for protocol FTP 


rip„Blockecl_Service„Violation 


A II 

All 

Monitors 


Denv FTP from anvone to nni/nriA 

t 

provided that Too Blocked Serving k 
true. 


FtpJDeny 


All 

Monitors 


Deny FTP from anyone to anyone 


Ftp_Anonymous_Authentication 


All 

Monitors 


Allow FTP-CONTROL_AUTHENTICATE 
with condition (Authentlcation_Rejected) t 
from Anon_User\o anyone 


Ftp_Val idate_Password 


All 

Monitors 


Allow FTP-CONTROl^AUTHENTICATE 
with conditions (Authentication_Rejected, 
Strong_Password), from anyone to anyone 


FtpJgnore_Data_Connections 




All 

Monitors 


Allow FTP-DAT A_OPEN from anyone to 
anyone 


Rules for protocol SSH 


Ssh_Validate_Handshake 


All Monitors 


Allow SSH-HANDSHAKE , SSH- 
SESSIONLABORTED with conditions 
(Ssh^uthentication^Failed, 
Ssh_Authentication_Aborted, 
Ssh_Secure_Authentlcation„Modes), 
from anyone to anyone 


Ssh_Blocked_Service_Violation 


All Monitors 


Deny SSH from anyone to anyone, 
provided that Tcp Blocked Services is 
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true. 


Ssh_Deny 


All Monitors 


Deny SSH from anyone to anyone 


Rules for protocol SSL 




ooi„vaiiaai©^nanasnaKe 


All Monitors 


Allow SSL-HANDSHAKE with conditions 
(Authentication_Rejected, 
SsLSesslon^Qos), from anyone to 
anyone 


S$LBIocked_Servlce_Violation 


All Monitors 


Deny SSL from anyone to anyone, 
provided that Too Blocked Sarvfcpa k 
true. 


Ssl_Deny 


All Monitors | 


Deny SSL from anyone to anyone 


SsLMissed_Handshakes 


All Monitors 


Allow SSL-MISSEDJHANDSHAKE from 
anyone to anyone 


Rules for protocol TCP 


Tcp_Blocked_Services_Response 


All Monitors 


Deny TCP-ABORT , TCP-CLOSE , TCP- 
TIMEOUT with condition 
(Tcp_Data_Xfer), from anyone to anyone, 
provided that Top Plocfad Secvfcf& is 
true. 


Tcp_Connection_Terminated 


All Monitors 


Allow TCP-ABORT f TCP-CLOSE f TCP- 
TIMEOUT from anyoneto anyone 


Tcpjteny 


All Monitors 


Provisionally deny TCP from anyone to 
anyone 


TcpJC_Shh_From„Clouds_To„Cgl 
.Provisional 


X_Monitors 


Provisionally allow TCP-CONNECT from 
Clouds to 
Tcp„X_Shh„From_Clouds_To_CgLProvi 
slonaLTarget 


Tcp_X_Spm_CollocJTraffic 


XJMonitors 


Allow TCP-CONNECT from Modin to 
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Tcp_X_Spm_.Colloc_Traffic_Target 


Tcp„X_Spm_Colloc„Traffic_Provis 
ional 


XJVIonitors 


Provisionally allow TCP-CONNECT from 
M o d 1 n to 

Tcp_X_Spm_Colloc„Trafflc_ProvislonaL 
Target 


Tcp_X„Ssh_From„Monkey_To„Flu 
ffy_Provisional 


X„Monitors 


Provisionally allow TCP-CONNECT from 
Monkey to 
Tcp_X_SshJ r romJMonkeyJTo^uffy__Pr 
ovisionaLTarget 


TcpJLX_Loghoet_Traffic 


XJMonitors 


Allow TCP-CONNECT from 
X_Web_Servers to 
Tcp_X_X„LoghosLTraffic_Target 


Tcp_X-Dns_From_Co1loc„To_Dns 
^Server 


X_Monitors 


Allow TCP-CONNECT from 
X„Coloc_Subnet to 
Tcp_X_Dns„From_Colloc_To„Dns_SGrve 
rJTarget 


Tcp J(_Port_1 984_Trafffic 


X_Monitors 


Allow TCP-CONNECT from 
X_Coloc_Subnet to 
Tcp__X_PorL1 984 JTraff ic_Target 


Tcp_X_S$h_To_Web_Server 


X_Monitors 


Allow TCP-CONNECT from X_Ssh__To„ 
Web_ServerJnitiator to Tcp_X_SshJTo_ 
Web_ServerJTarget 


TcpJC_Ssh„From_Fluffy„To„Wlonk 
ey_Provislonal 


X_Monitors 


Provisionally allow TCP-CONNECT from 
Fluffy to 
Tcp_X_Ssh_From_Ruffy_To_MonkeyJ 3 r 
ovisionaLTarget 


Tcp_X_Ssh_From_X_To_X_Web_S 
ervers„Provisional 


X_Monitors 


Provisionally allow TCP-CONNECT from 
X_Ssh_From_X_To_X_Web„Servers_Pro 
visional^lnitiator to 
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Tcp_X„Ssh_From - X_To„X„Web_Server 
s_ProvisionaLTarget 


Tcp_X_Http_From_Any_To_AII_We 
b_Servers_Provisional 


X_Monitors 


Provisionally allow TCP-CONNECT from 
anyone to 

Tcp.X.Http.From^Any^To^AILWeb^Ser 
vers_Provisional_Target 


Tcp_X_Stmp_From_AILTo_X 


X„Monitors 


Allow TCP-CONNECT from 
X_Stmp_From_AILTo_XJnitiator to 
_Smtp 


Tcp_Blocked_Services 


All Monitors 


Provisionally deny TCP-CONNECT from 
anyone to anyone 


Tcp_Mlssed_Connections 


All Monitors 


Allow TCP-MISSED_CONNECT from 
anyone to anyone 


Tcp_Blocked_Services_Violation 


All Monitors 


Deny TCP-PROTOCOL_UNKNOWN from 
anyone to anyone, provided that 
Tcp Blocked Services is hi in. 


Tcp_Unknown_Protocol 


All Monitors 


Deny TCP-PROTOCOL_UNKNOWN from 
anyone to anyone 


Rule? for protocol UPP 


Udp_XJ}nsJ r rom„Colloc„ToJ)ri 
s_Server 


X_Monitors 


Allow UDP-ASSOCIATION from 
X_Coloc_Subnet to 
UdpJ(JDnsJ=romj:ollocjroJDns_Serv 
erJTarget 


Udp Deny 


All Monitors 


Deny UDP from anyone to anyone 


Rules for protocol ICMP 


Icmp_Within_X 


X_Monitors 


Allow ICMP-ASSOCIATION from anyone 
to anyone, provided that Ip Within X is 
true. 
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1 

lcmp_Deny 


All Monitors 


Deny ICMP from anyone to anyone 


Rules for protocol IP 


lp_Directed_Broadcasts_Within„ 
X 


X_Monitors 


Allow IP-ASSOCIATION from 
lp_Wlthln_X_Jnltiator to 
lp„Directed„Broadcasts_Within_X„Target 


lpJ5xtemaLCommunitiesJTo_X 


X_Monitors 


Provisionally deny IP-ASSOCIATION from 
X_ExtemaLCommunities t o 
A_ooioc_buonet 


Ip^XJToJExternaLCommunitles 


X_Monitors 


Provisionally deny IP-ASSOCIATION from 
X_Coloc__Subnet t o 
X_ExtemaLCommunlties 


lpJMthln_X 


X__Monltors 


Provisionally deny IP-ASSOCIATION from 
lp_Within_X_lnitiator\o X_Coloc_Subnet 


lp_Non„Directed_Broadcasts_Wit 
hinJC 


XJVIonitors 


Allow IP-ASSOCIATION from 
lp__Within_X_lnitiator to 

Generic„MulticastjAncLBroadcasLAddr 

esses 


lp„Deny 


All 

Monitors 


Deny IP from anyone to anyone 


lp_Unknown_Protocol 


All 

Monitors 


Deny IP-PROTOCOL_UNKNOWN from 
anyone to anyone 



Algorithm for Efficient Rule Evaluation 
5 The preferred embodiment of the invention comprises a technique for a policy 
engine internally to organize policy rules in order to effect an efficient 
evaluation of protocol events at runtime. Evaluation of a protocol event 
entails selecting one or more applicable policy rules using an evaluation 
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algorithm. The preferred evaluation algorithm is described in A Declarative 
Language for Specifying a Security Policy, U.S. patent application number 
09/479,781 (1/7/2000). An excerpt describing the preferred evaluation 
algorithm is provided below in Table Q. 

5 

Using this technique, policy rules are organized in a manner that minimizes 
the number of rules that need to be considered when determining the set of 
rules applicable to a given protocol event. The algorithm is described with 
reference to Fig. 13 as follows: 

10 

• Create a first associative array, such as, for example, agent-to-protocols, 
where the key is an agent descriptor and the value is a reference to a 
second associative array with all the policy rules applicable to network 
traffic monitored by that agent (3001); 

15 

• Create a second associative array, such as, for example, protocol-to- 
actions, where the key is a protocol name and the value is a reference to a 
third associative array with all the policy rules applicable to that protocol 
(3002). 

20 

• Create a third associative array, such as, for example, action-to-rules, 
where the key is a protocol action and the value is a list of references to 
the policy rules applicable to that protocol action (3003). The rules 
referenced in this list (3004) are sorted in decreasing order of rank 

25 number, taking into account any constraints such as, for example, rank- 
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above, that might be present. Rules with the same rank number are 
ordered in the lexical order of their names. 

It should be noted that the same rule can be referenced by different lists of 
5 ordered rules and, in each list, can have different rank numbers because the 
ranking of a rule is relative to the ranking of the other rules in the same list. 

Assessment Tool 

The preferred embodiment of the invention provides an assessment tool that 
10 allows the discussed technique for continuously assessing the security of a 
system to be applicable to both long-term and short-term network 
assessment. The tool provides an additional dimension to network 
assessment. That is, it provides the ability to capture and classify, large 
volumes of network traffic efficiently, based on a formal policy which describes 
15 permitted traffic. The tool adds network usage to the known list of features 
discussed in an assessment framework. 

It has been found through field experience that the invention can be useful in 
the following contexts: 

20 

• Identifying services that were not mentioned by the system administration 
staff of a network that is being assessed; 

• Identifying usage patterns of critical machines. In an assessment 
25 framework, this applies to typical usage patterns, because a long-term 
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deployment of the invention is needed to continuously analyze and monitor 
changes in usage or rare aberrant behavior; 



• Identifying services; and 

5 

• Analyze routing patterns. It should be appreciated that subnets are not 
scanned. 

It should be appreciated that using the invention as a supplemental process in 
10 performing network assessments results in at least the following benefits: 

• Rather than providing an inference of possible network behavior that is 
based on what hosts are configured to do, the network behavior is directly 
analyzed based on direct observation of data traffic; 

15 

• Rather than basing security analysis on a static snap-shot of the network 
environment as it existed at a particular moment, the analysis is based on 
a dynamic recording of network behavior over some non-trivial amount of 
time. As an analogy, traditional known network vulnerability scans take 

20 still photographs, while the invention takes a motion picture; 

• Instead of relying on the accuracy of information provided by the customer 
point of contact through an interview process, the invention provides 
specific and tangible data points for discussion that facilitates the interview 

25 process and educates the customer on problems in an immediate 
feedback loop; and 
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• Because the invention is policy based, and because of the rigor built into 
the policy language and analysis engine, the otherwise manual (and hence 
error prone) analysis of security issues relative to the business and 
5 architectural context are enforced with a precise methodology which 
greatly reduces errors and omissions during the assessment process. 

It should be appreciated that because the invention operates passively, the 
customer network can be monitored while in normal operation or production. 

10 

Operational Description 

An example of implementing the assessment tool is described in the following 
discussion. A consultant arrives at a customer office with one or more 
workstations with the monitoring invention discussed herein loaded. The 

15 workstation, or station for short, may be a laptop computer, or other suitably 
portable platform. The monitoring station is attached to the customer network 
at a critical network bottleneck, e.g. just inside an Internet firewall, and 
monitors all traffic at that point in the network. From a security point of view, 
the monitoring station is entirely passive and Invisible to the network. The 

20 monitoring station only receives packets and does not respond to any protocol 
actions. Due to the monitoring station's passive nature, no operational impact 
is imposed on the subject network. Hence, assessments may be performed 
during peak production times, as well as when a network is in a quiescent 
state. 

25 
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In this example, the monitoring station is left attached to the network for a long 
period of time, depending on conditions, such as, for example, the practical 
demands of the visit, storage space on the station, and the amount of traffic 
on the customer's network. If appropriate, the station can be left at the 
5 customer site to gather data over a short-term period, such as, for example, 
days and weeks. 

In this example of an assessment situation, the policy specification is used to 
remove from consideration as much mundane network traffic as possible, 

10 allowing the analyst to concentrate on more interesting traffic. Due to the 
opinion of the analyst being part of the assessment process, there is no fixed 
goal for the level of detail needed in the policy specification. In the simplest 
case, the analyst generates no policy at all, and examines the network events 
one by one (perhaps using the query tool to filter them). In practice, it can be 

15 suggested that the analyst undergoes a short policy development phase, as 
the short policy development phase can serve the analyst well to reduce 
thousands of network events into a page or two, which may then be examined 
by inspection. 

20 The invention allows data to be stored in full packet form for most detailed 
analysis, or in compressed form storing only security-sensitive events. The 
latter form also removes customer-confidential information, such as, for 
example, embedded passwords, so that it Is more appropriate for removal 
from the customer site. A typical usage scenario is capturing full-packet data 

25 in a short burst, such as, for example, five minutes. After a brief analysis, a 

longer data collection is run using the compressed form. 
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The preferred embodiment of the invention provides the following algorithm 
for an operator, such as an analyst, to perform the data analysis on a data 
packet or on a compressed file of data. The algorithm is described referring 
5 to Fig, 14, as follows: 

1) Create a null policy, which denies all actions, for a customer site (copying 
a file). Set null policy to the current policy (4002); 

10 2) Run the policy engine discussed herein over the input data and using 
current policy (4002), and store the resulting data in a local database 
(4003); 

3) Using the query tool discussed herein, examine the network traffic that is 
15 declared in violation by the current policy (4004); 

4) Categorize the most frequent traffic based on customer input: 

a) If the traffic matches known customer-supplied input patterns, add this 
20 traffic to the policy with an OK disposition (4005); 

b) If the traffic does not match customer-supplied input patterns, but has 
high volume, add this traffic to the policy with an OK,monitor disposition 
(4006) . 

25 
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5) Repeat from step 2 (4009) until only a small, manageable number of 
events remains (4007). Then end the algorithm (4008). 

It should be appreciated that the same packet or compressed file is run by the 
5 policy engine multiple times. 

It should be appreciated that in an assessment situation a policy can be 
edited by using the policy generator discussed herein. The invention provides 
for using the policy generator for rapid policy development based on 
10 transport-level parameters. Enhanced policy development, using more 
complex tools, typically is not necessary in an assessment situation. 

It should also be appreciated implementing the algorithm discussed above 
does not take very long. Part or all of the process may take place at the 

15 customer site, in a hotel room, on an airplane, or back at the analyst's office, 
for example. When the process is completed, the analyst has a list of 
monitored network events. This list is used as a basis for additional 
discussion with the customer to determine the meaning of such events. 
Experience has shown that such conversation is useful to the assessment 

20 interviewing process. 

It should also be appreciated that the variations of the algorithm above can be 
implemented and are within the scope of the invention. Examples of 
variations follow. 

25 
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Example Variation I 

An equally preferred embodiment comprises the analysts first determining the 
customer requirements and the customer network credentials. Using this 
information, the analyst programs an initial policy. The analyst can derive and 
5 use additional information from the scanning process as described in the 
algorithm above. 

Example Variation II 

The customer or analysts designs an initial best policy as a set of credentials 
10 and rules, set all dispositions to DENY, and monitors the network to determine 
what the dispositions should be. 

Credential / Condition A ssertion Verification Op timization 
In the preferred embodiment of the invention, the policy language describes a 

15 policy decision involving two principals, an initiator and a target principal. 
These principals are identified by a set of one or more credentials. For each 
policy decision the policy engine ascertains which credential in the policy best 
describes the information about the principals involved in an interaction. 
Similarly, the policy language herein describes conditions that in turn describe 

20 tests performed on the state of an associated protocol event. 

The preferred embodiment of the invention provides a credential / condition 
assertion verification optimization algorithm to ensure that the choice of 
credentials and conditions are made as efficiently as possible. 

25 . 

83 



WO 01/99349 



PCT/US01/18669 



To accomplish credential / condition assertion verification optimization, the 
policy engine: 



• During the initialization process dynamically creates comparing functions 
5 for principals with credentials, and comparing functions for state of 
protocol events with particular conditions in a high level language such as 
C++; 



■ Dynamically creates and loads a module containing the comparing 
10 functions; 



■ During runtime ensures that installed policy file matches module 
containing comparing functions, otherwise generates new module 
containing comparing functions that correspond to installed policy file; and 

15 

■ Calls comparing functions as appropriate. 



20 



25 



The preferred embodiment provides a more rigorous algorithm, an example of 
which is described in Table M below. 

T able M 

During the initialization process of the policy engine: 

• the policy engine requests that the parser module load a policy file, comprising 
credentials and conditions into an in-memory representation; 

• the policy engine requests that the parser module load an assertion verification 
dynamically loadable library (DLL); 
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10 



15 



if this DLL exists then 

• it is loaded into memory; and 

• a predetermined function, for example named dllValidateFunc(), contained in 
the loaded DLL is called, if the return value of the function call is the same 
as a MD5 hash of the previously loaded policy file, then loading is complete. 
Otherwise execution initialization continues below; 

because the DLL does not exist or because the MD5 hash does not match, a 
code generation function of the parser module is invoked, which: 

• adds header information to a C++ assertion code file; 

• adds a function that returns the MD5 hash of the policy file that was used to 
generate this C++ file; 



• iterates through credentials contained in the in-memory representation, 
20 generating C++ function prototype and function declarations for code that can 

compare a principal description with the definition of a credential into the 
assertion code file, wherein such comparison is performed by: 

• calling other credential comparison methods for any credentials used in 
25 the definition of the credential under test; 

• making calls to the policy engine module to perform comparison 
operations based on allowable operations for the built-in types of the 
policy language; and 

30 
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• combining the results of the above tests with logical operators AND, OR 
and NOT; 

iterates through the conditions contained in the in-memory representation, 
generating C++ function prototype and function declarations for code that can 
compare a protocol state description with the definition of a condition into the 
assertion code file, wherein such comparison is performed by: 



• calling other condition comparison methods for any conditions used in 
"10 the definition of the condition under test; 

• making calls to the policy engine module to perform comparison 
operations based on the allowable operations for the built-in types of the 
policy language; and 

15 

• combining the results of the above tests with logical operators AND, OR 
and NOT; 



♦ compiles and links this generated C++ file to create a dynamically loadable 
module containing a compiled version of the principal/credential and 
protocol/condition comparison functions; and 

• loads this newly created module. 



25 During the runtime of the policy engine: 

• each time that it needs to decide whether a principal is described by a particular 
credential it computes the name of the comparison function based on the name 
of the credential to be tested; 



30 



calls the comparison function which returns a Boolean value that represents 
whether the credential under test matches the principal under test; 
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• each time that It needs to decide whether a protocol state satisfies a particular 
condition it computes the name of the comparison function based on the name of 
the condition to be tested; and 

• 5 

• calls the comparison function which returns a Boolean value that represents 
whether the condition under test satisfies the protocol state under test. 



Network Monitor Internals Descrip tions 
10 The preferred embodiment of the invention provides a network monitor 
internals mechanism discussed below that serves to translate packet data into 
multiple concurrent streams of network event data. It accomplishes this by 
interpreting both sides of each protocol transaction. 

15 Fig. 15 shows a high level schematic diagram of the network monitor 127 
accepting packet data from either a live network interface 125 or a file 
containing packet data 126. The network monitor extracts security-sensitive 
details from the input packet stream 125, 126, and generates output in a 
serialized stream of encoded network event information 115. The preferred 

20 encoded format is DME encoded format, discussed below in section, Network 
Event Encoding Format. The output network event information can be stored 
for logging or debugging purposes, or can be passed directly to the policy 
engine. Thus, the discussed network monitor provides an efficient process of 
exporting data from a customer's site, such process comprising extracting 

25 security-sensitive information. 
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Fig. 16 shows a schematic diagram of process flow according to the invention. 
The network monitor 1 27 is a single-threaded program that processes packets 
(125 or 126) as they are read. Each packet is passed to a monitor protocol 
engine 6100 for processing. When security-sensitive protocol events are 
5 encountered in the packet data, the monitor calls into its output section 6200 
to transmit network or protocol events to the rest of the policy monitoring 
system 100 via a network pipe, direct procedure call. Output section 6200 
can also store protocol events in a file for later processing. 

10 Protocol Engine 

The preferred embodiment of the invention provides a protocol engine in the 
network monitor that can be described with reference to Figure 17, which is a 
block schematic diagram of features of the protocol engine according to the 
invention. Input packet data 115 is read into a known object-oriented 

15 structure type 6101, such as, for example, a C structure here named pkt_t 
structure. The pkt_t structure 6101 represents a packet on the network. It 
provides a stack-based structuring mechanism 6102 that allows protocol 
headers and trailers 6103 to be marked in the packet so that software may 
focus easily on the correct protocol layer. The pkt_t structure 6101 also 

20 includes generic src 6104 and dst 6105 address locations, and flags 6106 to 
pass useful information up and down a connection stack, for example, if such 
packet is transiting from server to client or vice versa. 

The protocol engine 6100 provides one module 6107 for each protocol 

25 implemented 6108. The modules implement a generic series of operations, a 

preferred example of such series is provided below in Table N. A common 
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connection structure 6109 allows connection data to be arranged in a stack 
allocation for each access across layer boundaries. In Java or C++ 
terminology, for example, each protocol is a superclass of connection. The 
layering permits protocols to assume one or more roles as the layer 
responsible for each corresponding boundary, such as, for example: Network, 
Transport, Session, Application, or Transactions. 

TflbleN 

Example of generic operations for each protocol implementation: 

1 . Init; Call-once initialization 

2. Bind(packet, connection): given the first packet of a connection, attempt to bind 
this packet into a new instance of this protocol within connection. Establish the 
instance in its proper role(s) within the connection. 

3. Input(packet, connection): given a packet, which has been associated with a 
connection (in some cases, connection is NULL, Indicating that no such 
relationship exists, or exists yet), process the packet as input to the connection. 

4. GlveBack(packet, connection): given a packet, which has been associated with a 
connection at a higher level of protocol, give back the packet to this layer, so that 
the data will be received later, as if it was retransmitted. Typically, packet has 
been modified to contain only part of the input data. 

5. GetMore(connection, amountNeeded, fromClientOrServer) returns(packet): given 
a connection, attempt to return a packet containing more data on the connection, 
if such is available. This call is used from a higher layer of protocol calling down 
to a lower layer of protocol. The fromClientOrServer argument is used to 



89 



WO 01/99349 



PCT/US01/18669 



determine if the data is being requested that was received by the server side or 
the client side of the connection. 

6. StopCoilecting(connection): given a connection, adjust the protocol stack so that 
no further data will be processed on this connection. Depending on the protocol 
in question, this may involve discarding data or adjusting filters. A connection 
which is not "collecting" attempts to process packets In the most efficient manner. 

7. Shutdown(connection, fromOrg, fromDst): given a connection, modify the 
connection state to indicate that the client, server, or both have acted to take 
down the connection. The full generality of the call is needed only for a transport 
connection like TCP. 

8. Del(connection): given a connection, arbitrarily delete the instance of this protocol 
from the connection object. This call is intended to clean up the resources used 
by the connection; Shutdown is used to indicate protocol agreement that the 
connection is coming to an end. 

9. Alaim(connection, time): given a connection and the current time, this call is used 
to signal an alarm has expired on this connection. The time argument is the 
official time of the alarm, which may not even be related to the current time. 

10. SwitchSrcDst(connectlon): this call Indicates that a higher layer of software 
(perhaps a higher level protocol) has determined that the choice of client and 
server In this protocol instance are wrong, and should be reversed. This may 
happen when initial connection negotiation packets are not seen by the monitor, 
but later information makes the client and server clear. 

It should be appreciated that in the stopCollecting generic operation, and in a 
transport protocol, header information in packets may need to be examined to 
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determine connection state, allowing freeing of resources when the 
connection terminates. Transport protocols discard all subsequent data from 
the connection, and do not forward packets on to higher level protocols. Such 
mechanism allows the monitor to efficiently process bulk transfers, encrypted 
5 connections, or connections that are no longer of interest to the policy engine. 

It should be appreciated that the process discussed above for the 
stopCollecting generic operation can be appropriate for a hardware filter to 
stop packets from arriving. 

10 

The concept of the current time in the monitor flows from the packet level 
upwards. That is, time is associated with the packet and is maintained 
throughout the packet. When the network monitor is running in real time off 
live packet data, current time reduces to the time a packet was received, 

15 which may be earlier than the time when the packet is processed. When the 
network monitor is running off stored packet data, current time in the monitor 
has no relation to actual current time. The packet is processed relative to the 
time it was received and whereby time intervals remain the same. Also, 
results can be lined up in the database reflecting the point of reference of the 

20 time the packet was received. 

The network monitor provides support for setting alarms on connections. An 
alarm is set by registering a connection to receive a signal when the network 
monitor transitions to a predetermined value of current time. The signal 
25 consists of a call to a generic alarm operation in every protocol layer 
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registered with such connection. Alarm handlers are called in order from 
lowest protocol layer to highest protocol layer. 

Because network monitor functionality is based on network events that can 
map to network connections, the network monitor provides a connectionless 
association feature. By using the feature, the network monitor registers the 
fact that it noticed two IP hosts communicating. Typically, an association is 
long lived, whether or not the network monitor knows its intention. Examples 
of associations are a series of ICMP PING / PING REPLY packets and a 
stream of IPSEC packets. The network monitor treats associations as 
connections. Indeed, often associations are connections at a higher level of 
protocol. 

Output Section 

The preferred embodiment of the invention provides an output section in the 
protocol engine. Fig. 18 is a high level flow diagram of the preferred output 
section according to the invention. The output section 6200 of the network 
monitor receives network event data from the protocol engine and generates 
outbound calls 6203 to transmit such data to the policy engine or to a file. 

The output section 6200 works by allowing the network monitor to establish a 
transaction which forms an association between a monitor connection and a 
network event in the policy engine. Fig. 19 shows a schematic diagram of a 
transaction 6204, comprising an association 6205 between a subject monitor 
connection 6206 and a network event 6207. Typically, the lifetime of the 

connection 6206, the transaction 6204, and the network event 6207 is similar. 
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The output section's interface comprises a set of calls to establish 
communication with the policy engine, and to start and finish transactions, and 
a set of protocol-specific calls. The calls progress as follows: 

5 

• Connect 

• BeginTransaction 

• ProtocolEventl 

• ProtocolEvent2 
10 • ... 

• EndT ransaction 

• Disconnect 

It should be appreciated that in addition to the calls above, multiple 
15 transactions can be active at a time, as long as each transaction follows the 
ordering described above. 

The output section internally translates such calls into a generic set of calls, 
an example of which is listed below. At initialization of the network monitor, 
20 the output section is configured with a chain of output generic modules, each 
of which is used as filter on the output data. An example of the implemented 
modules follows: 

• NULL: acts as an endpoint, but discards input data without doing anything; 

25 

• SM: connects by procedure call directly to policy processing; 
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• ENC; generate encoded form of output; and 

♦ LOG: generate textual form of output. 

5 In an equally preferred embodiment of the invention, the network monitor also 
includes an input section that decodes an encoded version of events. For an 
example application, in a real-time monitoring system embodiment the 
monitor 127 processes network traffic 125 in real time and uses ENC to 
generate encoded output. The encoded output is transmitted in real-time over 
10 a TCP connection where it is decoded and connected using SM to the Policy 
Engine 102. 

In another embodiment of the invention, the output section is used for testing 
purposes. The output section is configured using command line arguments. 
15 An example of an algorithm for such testing follows: 

1 . Capture packet data into a file; 

2. Run the network monitor on the packet data, using LOG^ENC. Store the 
20 logged textual data and the encoded form into separate files; and 

3. Run the network monitor on the encoded data, using LOG->NULL. Store 
the logged textual data in a file. 

25 4. Compare the two textual files to make sure that the decoded version 
matches the logged textual file. 
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Network Event Encoding Format 

The preferred embodiment of the invention provides a technique for network 
event encoding to be used by the network monitor. The encoding technique 
5 is designed for both archival and transmission purposes. The basic format of 
the encoding is: 



• Header 

• Embedded agent descriptors 
10 • Type map 

• Encoded transactions 



An example of the preferred form of the header follows: 

• 4 byte magic number: "SMKo" 
15 • 1 byte major version = 2 

• 1 byte minor version = 1 

• 4 bytes containing the size of this header 

• 8 bytes (struct timeval) begin time, which is a time which is iess than or equal to every 
timestamp in this encoded record 

20 • 4 bytes offset of agent descriptor section 

• 4 bytes indicating number of agent descriptors 

• 4 bytes offset of type map section 

• 4 bytes indicating number of type map entries 

• 4 bytes offset to first transaction record 

25 • 4 bytes size of this file, or OxFFFFFFFF if unknown. 

• 4 bytes 1 's complement checksum of this file or OxFFFFFFFF if unknown 
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The agent descriptor section is used to store a possibly null list of agent 
descriptors that are configured into the network monitor at encoding time. 
The agent descriptors are strings that plug into a particular policy language 
policy. They indicate the location of the subject monitor in the subject network 
5 wiring structure, enabling rules that apply to such location in the network and 
disable rules that do not apply. 

A preferred agent descriptor section comprises an array, where each element 
of the array is an ASCII string, preceded by a single byte giving its length. 
10 The size of the array is given in the header cited above. 

The preferred type map section is used to improve maintainability of the full 
policy monitoring system. Provided by the type map section is a mapping 
between update types used in an encoded record and the update types' string 
15 names. The decoding module uses this information to detect new update 
types that are not supported by mapping known updates to the correct values. 
That is, because new update types typically are not interpretable by old 
software, they are therefore successfully skipped. 

20 A preferred type map section comprises an array,, where each element of the 
array contains a four-byte type value, a single byte of string length, and the 
ASCII name of the type. The size of the array is given in the header cited 
above. 
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The preferred encoded transactions comprise an array of individual update 
encodings. The size of the array is either derivable from the header file size 
information, or is unbounded, such as, for real-time monitoring. 

A preferred header for an individual update has the following format: 

• 1 byte, giving the update type 

• 4 bytes, giving the size of this header in bytes, not including the length of the header 

• 8 bytes (struct timeval) giving the absolute time when this update occurred 

• 4 bytes, giving the packet number of this update since the monitor started (first packet = 
packet #0) 

• 4 bytes, giving the eventID of this update, which is the number of BEGINJTRANS 
updates that occurred before this one, since the monitor started 

Following the header a body contains additional update-type-specific data, or 
possibly none. 



To understand all events that transpire on a connection, it is necessary to 
combine events of different protocol layers. For example, an update, named 
SMJP^ASSOCIATION, provides IP src and dst addresses and establishes a 
peer relationship. Subsequent events assume that this information is known 
and builds on it. For example, an update named ICMP_ECHO has no body at 
all. 



An example of a set of update types and corresponding encoding body for 
each update, according to the invention is given below in Table O. The 
meaning of the term "string" is: // length(string) is < 255, then byteflength], 
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byte[string][length], else byte[0xff], byte[a], byte[b], byte[c], byte[d], 
byte[string][length] where a,b,c,d are the four (big-endian) bytes of length. 

Table o 

5 SM_BEGIN_TRANS 

Body: none 

Meaning: begin new transaction (network event) 

SMJENDJTRANS 
1 0 Body: none 

Meaning: end previously "begin" transaction (network event) 

SM^PUOSU 
Body: none 

15 Meaning: the monitor can glean no more useful Information about this network event. 

The policy engine should process policy and give additional input to the monitor. 

SM_DEBUG_MSG 
Body: string 

20 Meaning: debug message, to be Inserted into SPM debugging log. 

SM_PROTOCOU.UNKNOWN 
Body: none 

Meaning: the monitor is unable to determine the higher level protocol 

25 

SM_FTP_DATAOPEN 
Body: none 

Meaning: This (new) connection is an FTP data connection 
30 SM_FTP_DATACLOSE 
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An Exemplary User Interface for Provi ding and Re porting PronmwBri «nH 

Analyzed Netwoifr Da ta to an End User 
An exemplary user interface for providing and reporting the processed and 
5 analyzed network data from the database (Fig. 1a - 165) to an end user is 
provided below. 

It should be appreciated that examples of a typical end user using such 
interface are, but are not limited to a customer whose network is being 
10 monitored, an operations analyst reviewing the customer's network 
environment and network data, and/or a policy analyst reviewing the network 
data and its conformance to network policy. 

The preferred embodiment of the invention uses a web page paradigm as an 
15 example of a type of user interface, and is described with reference to figures 
of screen prints of web pages herein. While the claimed invention herein has 
disclosed a web page implementation of a user interface, it will be appreciated 
by those skilled in the art that such user interface readily encompasses any 
form, that can be substituted therefore to effect a similar result as is achieved 
20 by the web page, including but not limited to any graphical user interface or 
non-graphical user interface. 

The preferred embodiment of the invention is described with reference to Fig. 
20 and comprises a system dashboard, label 20000 on a home page, wherein 
25 the dashboard 20000 is kept up to date with current monitoring information 
from the monitored network. 

153 



WO 01/99349 



PCT/USO 1/18669 



In the preferred embodiment of the invention, the dashboard 20000 updates 
once every five minutes. It should be appreciated that different update rates 
can be used to keep the data on the dashboard 20000 current, and that parts 
5 of the underlying customer data may be updated at a different, such as a 
slower rate. 

The preferred embodiment of the invention provides a tear off feature on the 
system dashboard 20000. In this example, the end user clicks on a tear off 
10 tab 20010 to open a tear off console window. Fig. 21 shows an example of a 
tear off console window according to the invention. It is intended that the end 
user keep the console window open on the computer desktop all day long to 
view high level reporting of the health of the monitored network. 

15 The preferred embodiment of the invention provides an outstanding alerts 
area 20020 of the dashboard and consists of a FIFO queue of CRITICAL 
alerts that have been generated by the policy monitoring system (Fig. 1a - 
106). In the preferred embodiment of the invention the following applies. The 
size of the alert list can be limited to a predetermined number of elements. 

20 The total number of open alerts can be displayed within the alerts area 20030. 

The underlying data is updated on a real-time basis. Entries in the list link to 

alert details, as depicted in Fig. 28. In this example, clicking on an entry in the 

list 20030 opens up an alert details page 2801 for that particular alert, 

25 comprising such alert details as, for example rule, disposition, time of alert, 

type of alert, source ip-address, destination IP-address, and the like. 
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The preferred embodiment of the invention provides a health monitor 20040 to 
show a visual representation of the severity categories into which the current 
observed traffic has been assigned over a predetermined amount of time. In 
this example, the underlying data is updated every five minutes and 
summarizes traffic over the last one hour and last twenty four hour periods. 
CRITICAL and HIGH severity alerts have a red bar 20050, MEDIUM, 
WARNING and MONITOR uses a yellow bar 20060, and all others are green 
20070. 

The preferred embodiment of the invention provides access to current 
summary reports. An example is shown in Fig. 20 as part of the end user's 
home page. Such screen allows the end user to generate queries that 
summarize report data filtered by the monitoring point and over configurable 
time periods. An interface feature, such as a dropdown listbox 20090 allows 
the end user to choose one of a predetermined set of time periods, such as 
but not limited to the following: 

• Select date range - A specific time period expressed in starting month, 
day and hour, followed by ending month, day and hour using an interface 
feature such as dropdown listboxes 20091; 

• Last two hours; 

• Last 24 hours; 



155 



WO 01/99349 



PCT/US01/18669 



• Today (since midnight); 

• Yesterday (00:00 - 23:59:59) ; 

• Last seven days; 

• This month (from first to present); 

• Last month (from first to end of month); 

• Last three months (three months back from present); and 

• Custom (retrieves date/time range from the last manually configured 
query). 

The preferred embodiment of the invention provides an events summary view 
as shown in Fig. 22. 

In the example shown in Fig. 22, viewing the summary for a specific time 
period displays both a chart 2201 of a predetermined number of columns and 
a table 2202 displaying the following information, when the conformance tab 
2203, the violators tab 2204, or the targets tab 2205, respectively, is selected: 

• A conformance chart/table shown in Fig. 22, displaying the count of 
violations for each rule/disposition pair. 
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■ An icon 2206 links to a network event details page, such as shown in 
Fig. 23 that contains details of events that make up this count, i.e. all 
network events with such rule/disposition pair that occurred in the given 
time period. 

■ A violators chart 2901 and table 2902 shown in Fig. 29, displaying the 
count 2903 of the number of violations for each of the top violating ip- 
addresses 2904. 

• An icon 2206 links to a network event details page, such as shown in 
Fig 23 that contains details of events that make up this count, i.e. all 
network events with such originating ip-address that occurred in the 
given time period. 

■ A targets chart 3001 and table 3002 shown in Fig. 30, displaying the count 
3003 of the number of violations for each of the top destination IP- 
addresses 3004. 

• An icon 2206 links to the a event details page, such as shown in Fig 23 
that contains details of events that make up this count, i.e. all network 
events with such destination IP-address and port that occurred in the 
given time period. 

Fig. 22 shows the events summary report for conformance. 
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The preferred embodiment of the invention provides a link to network events 
detail information. In this example, a separate link 2206 builds a network 
events details page as shown in Fig. 23. Fig. 23 contains a table that may be 
sorted or reverse sorted by any of the columns displayed 2301 of all violating 
5 network events with such a rule/disposition pair that occurred in the chosen 
time period. 

In the preferred embodiment of the invention, the summary page (Fig. 22) 
contains a specification of the date range of the data being displayed. In 
10 particular, if the start of the range falls outside the range of date for acquiring 
user data then the actual start date of the user data is displayed. 

It should be appreciated that in another equally preferred embodiment, user 
defined and configurable query and reports settings can be stored, for 
15 example, in a user's preferences or profile. 

The preferred embodiment of the invention comprises trend reports on the 
dashboard, wherein such reports comprise charts that link to a network' events 
summary page containing details of the summarized traffic. More specifically, 
20 the charts, unless otherwise explicitly specified, are bar charts, each of which 
link to the network events summary page. 

Referring to Fig. 20, the preferred embodiment of the invention comprises a 
section, such as a QuickWeek section 20100 of the end user's main page, 
25 such as a login page or home page that contains trend graphs, such as but 
not limited to the following: 

158 



WO 01/99349 



PCT/US01/18669 



• During the past seven days, the five most frequent rule/disposition 
combinations versus count 201 10; 

5 • During the past seven days, the five most frequent violator ip-addresses 
versus count 20120; and 

• During the past seven days, the five most frequent target ip-addresses 
versus count 20130. 

10 

It should be appreciated that another equally preferred embodiment of the 
invention comprises an input means for the end user to customize which 
trends appear in the trend, e.g. QuickWeek section, and to customize the time 
period being viewed. 

15 

The preferred embodiment of the invention comprises trend charts that are 
embedded into details pages. Each of the trend charts allows the end user to 
dynamically configure a time range by a means such as a pull down menu. 
Examples of such embedded trend charts are: 

20 

• Policy effectiveness; 

• Number of policy changes over time; 

25 ■ Event Summary (such as for the following): 
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Graphical view of the data for the specified time 



■ Violators: Graphical view of the data for the specified time period; and 

■ Targets: Graphical view of the data for the specified time period; and 



" Network Event Details (such as for the following): 



■ Conformance Event Details (Fig. 23):Violator count over time for a 
particular rule/disposition combination 2303; 

• Violators Event Details: Conformance count over time for a particular 
violator, and 

• Target Event Details: Conformance count over time for a particular 
target; 

• All, e.g. in chronological order:Conformance count over time for a 
particular time period. 



The preferred embodiment of the invention provides event detail reports, such 
as for but not limited to network event details, protocol event details, and alert 
details, described below. 
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The preferred embodiment of the invention provides a network event details 
page containing listed fields in columns that vary according to the violation 
type, such as, for example, All, Conformance (Fig. 23), Violator, and Target 
that had been selected at the summary level. For each type, except All, 
5 rather than repeat the field or column(s) which reiterate the violation, it will be 
displayed in the heading of the events detail page. For example, after 
choosing to view event details for a particular target, the DstIP is not repeated 
in every row. Each of the columns may be used to sort or reverse sort the 
report by clicking on that column's heading name. Following is a list of types 
1 0 of data provided in a network event details page: 

• Monitoring Point; 

• Disposition Name; 

15 

• Rule Name; 

• Disposition Code; 
20 • Severity; 

• Src IP; 

• Src Port; 

25 

• Dst IP; 
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• Dst Port; 

• IPProtocol; 

5 

• Event Time: event times can be stored throughout the system in UTC; and 

• Application Data: 

10 • ICMP - ICMP action code; 

• HTTP -URL; 

• FTP - Filename; 

15 

• SSL - Ciphersuite, Issuer and Subject's certificate CommonName, 
Certificate Status; 

• SSH - Authentication handshake status; and 

20 

• Application Status Code 

• HTTP - StatusCode. 

25 The preferred embodiment of the invention provides a protocol event details 

page as depicted in Fig. 24 and that is created in the context of a particular 
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network event instance. This data is retrieved on an as-needed basis from a 
database. The content of this page reflects the data available in a protocol 
event view of the QueryTool and is specific to the protocol or protocols being 
displayed. Such data includes, but is not limited to: 

5 

• Data from such attributes as IP address, interface address, protocol ID, 
service port, URL, file pathname, user name, password metrics, public key 
certificate, encrypted session parameters and status codes; and 

10 • Protocol-specific actions such as HTTP methods, TCP protocol messages, 
ICMP message codes, FTP control commands, and authentication steps. 

The preferred embodiment of the invention provides an alert event details 
page as depicted in Fig. 28 containing, but not limited to the following: 

15 

• details of the network event that caused the alert; 

• rule and disposition name that triggered alert; 
20 • log comment from the disposition; 

• time at which the alert was generated; 

• initiator ip address of the corresponding non-conformant traffic; 

25 

• target ip address of the corresponding non-conformant traffic; 
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• an icon that links to the network event details page describing the non- 
conformant network event; and 

5 • checkbox to clear the alert. 

The preferred embodiment of the invention provides a policy update page 
containing, but not limited to a table displaying each time a new policy is 
installed on the security policy management system discussed herein. This 
1 0 table contains, but is not limited to: 

• Date of the policy installation; 

• Description of policy; and 

15 

• A link to the English description that represents the newly installed policy. 

It should be appreciated that in the preferred embodiment of the invention 
alerts are generated whenever a disposition with a CRITICAL severity is 
20 assigned to a network event, each alert generating an email containing, but 
not limited to the following information: 

• time the alert occurred; 

25 • rule and disposition name that triggered alert; 
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• initiator ip address of the corresponding non-conformant traffic; 

• target ip address of the corresponding non-conformant traffic; and 

• link to the network event detail describing the non-conformant network 
event. 

The preferred embodiment of the invention provides a customer page that 
allows the user to configure a list of email addresses within a customer's 
organization that shall receive alert email. 

Another equally preferred embodiment provides means for accessing ad-hoc 
queries for the end user, such as, but not limited to, filtering results by any 
one or all of the following: 

• Protocol of the rule name; 

• Policy rule name; 

o A regular expression within the rule name; 

• Disposition name of the violation; 

o A regular expression within the disposition name; 
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• Source ip-address; 

o A regular expression with source ip-address; 

5 

• Target (Destination) ip-address; 

o A regular expression within target (destination) ip-address; 
10 • Target (destination) port; and 

o A regular expression within target (destination) port. 

An example of a means for accessing ad-hoc queries is an advanced search 
15 feature, such as for example, an advanced search dialog box 3100, as 
depicted in Fig. 31. In the preferred embodiment of the invention, the 
advanced search dialog box 3100 comprises list boxes for such categories, 
such as protocol 3101, rule 3102, and disposition 3103, and text boxes for 
descriptions, such as regular expression in a rule 3104 or disposition 3105 
20 and IP-addresses 31 06. 

In the preferred embodiment of the invention, an end user can open the 
advanced search dialog box 3100 from an Advanced Search link 3201 on the 
dashboard, as depicted in Fig. 32, or from any event summary or event details 
25 page. 
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The preferred embodiment of the invention provides informational aids. For 
example, the following information about a user's policy is available via a 
variety of features, such as but not limited to links, tool tips, and the like: 



• Customer specific policy interpretation, such as provided by English 
language representation; 

• Rule and disposition descriptions as defined by the user in the user's 
policy, resolved DNS names for ip-addresses, and TCP and UDP service 
names; and 

• A copyright page containing copyrights and trademarks as required by 
licensing agreements with vendors. 

The preferred embodiment provides links to descriptions of rules, dispositions, 
IP-addresses, and the like, displayed, for example in a pop up window 
whenever the user's cursor is over the respective field, as depicted in Fig. 22 
2207, Fig. 23-2302, Fig. 25-2501, Fig. 26-2601, and Fig. 27-2701, 
respectively. 

The preferred embodiment of the invention provides links on each page that 
include, but are not limited to: 

• Context sensitive help per-page. 
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In the preferred embodiment of the invention, each details page contains a 
button linking to a printer friendly version of the page. 

In the preferred embodiment of the invention, regardless of the time zone the 
user's or the policy monitoring systems runs on, such as, for example 
Universal Time Coordinates (UTC). Any time being displayed to the user, 
such as, for example, on a website or in contents of emails, is converted to 
the user's time zone and as such is explicitly displayed. 

Although the invention has been described in detail with reference to 
particular preferred embodiments, persons possessing ordinary skill in the art 
to which this invention pertains will appreciate that various modifications and 
enhancements may be made without departing from the spirit and scope of 
the claims that follow. 
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C IA1MS 

1 . An apparatus for adding network usage to an assessment framework 
5 by providing ability to capture and classify large volumes of network traffic 

efficiently based on a formal policy specification describing said traffic, said 
apparatus comprising: 

means for identifying network services; 

means for identifying usage patterns of critical machines on said 
10 network; 

means for analyzing routing patterns; and 

thereby reducing errors and omissions during an assessment process. 

2. The apparatus of Claim 1, further comprising identifying services 
15 and/or data points not previously identified by system administration staff of 

said network. 

3. The apparatus of Claim 1, wherein subnets are discovered by 
analyzing routing patterns, without the need to scan for subnets. 

20 

4. The apparatus of Claim 1, wherein said means for analyzing is based 
on a dynamic recording of said network traffic over time. 

5. The apparatus of Claim 1, wherein said capturing network traffic is 
25 performed in a passive way. 
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6, The apparatus of Claim 1, wherein said capturing traffic is performed 
during normal operation or production. 



7. A method for an end user to add network usage to a network 
assessment process, said method comprising: 

attaching a monitoring station to a network, wherein said station is 
nonintrusive to said network; 

said station receiving network packets over a period of time; 

removing undesirable network events of said received network 
packets; 

performing data analysis on remaining network events; and 
determining a list of network events from said analyzed remaining 
network events to use in said network assessment process. 

8. The method of Claim 7, wherein said removing undesirable network 
events uses a policy specification, 

9. The method of Claim 7, wherein said monitoring station is portable. 

10. The method of Claim 7 f wherein said station is attached at a critical 
bottleneck of said network. 

11. The method of Claim 7, wherein said receiving said network packets is 
done at any time, including, but not limited to at peak production time and at a 
quiescent state of said network. 
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12. The method of Claim 7, wherein said period of time is of any length 
including, but not limited to long or short. 

1 3. The method of Claim 7 further comprising: 

using a query tool to filter said undesirable network events. 

1 4. The method of Claim 7, further comprising: 

storing said received network packets in full-packet form or 
compressed form. 

15. The method of Claim 14, wherein said compressed form removes 
confidential information. 

1 6. The method of Claim 7, further comprising: 
incorporating iterative methodology. 

1 7. The method of Claim 1 6, further comprising: 
developing a short policy as a result of a first iteration; and 
using said short policy in a subsequent iteration. 

1 8. The method of Claim 1 6, further comprising: 

capturing said received network packets in a full-packet form over a 
significantly short duration of time; 

performing brief analysis on said captured packets; and 
subsequently capturing more network packets in compressed form 

over a significantly long duration of time. 
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1 9. The method of Claim 1 6, said iterative methodology further comprising: 
using said received network packets or a compressed file multiple 

times. 

20. The method of Claim 8, wherein said policy specification is edited using 
a policy generator tool. 

21. The method of Claim 7, wherein said performing data analysis takes 
place at a location different from said network and/or at a time subsequent to 
said period of time. 

.22. The method of Claim 8, said performing data analysis further 
comprising: 

creating a null policy denying all protocol actions of said network 
events; 

setting said policy specification to said null policy; 

running a policy engine over received network packets using said 
policy specification, and storing said results in a database; 

examining said stored results using a query tool, and determining from 
said examined results network events in violation of said policy specification; 

categorizing most frequent traffic from said violating network events 
based on predetermined input; and 

repeating from running a policy engine with said categorized most 
frequent traffic until a small and manageable number of events remain. 
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23. The method of Claim 22, said categorizing further comprising: 

if said traffic matches predetermined patterns, adding said traffic to 
said policy specification with an OK disposition; and 

if said traffic does not match predetermined patterns, but has high 
5 volume, adding said traffic to said policy specification with an OK, monitor 
disposition. 

24. The method of Claim 22, further comprising: 

setting said policy specification to an initial policy, said initial policy 
10 comprising predetermined requirements and predetermined network 
credentials of said network. 

25. The method of Claim 22, further comprising: 

setting said policy specification to an initial best policy, said Initial best 
15 policy comprising a predetermined set of credential and rules, setting all 
dispositions to DENY, and monitoring said network to determine ultimate 
dispositions. 

26. A method for performing data analysis on a network packet or on a 
20 compressed file of network events, said method comprising: 

creating a null policy denying all protocol actions of said network 
events; 

setting a policy specification to said null policy; 
running a policy engine over said network packet or said compressed 
25 file using said policy specification, and storing said results in a database; 
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examining said stored results using a query tool, and determining from 
said examined results network events in violation of said policy specification; 

categorizing most frequent traffic from said violating network events 
based on predetermined input; and 

repeating from running a policy engine with said categorized most 
frequent traffic until a small and manageable number of events remain. 



27. The method of Claim 26, said categorizing further comprising: 

if said traffic matches predetermined patterns, adding said traffic to 
1 0 said policy specification with an OK disposition; and 

if said traffic does not match predetermined patterns, but has high 
volume, adding said traffic to said policy specification with an OK, monitor 
disposition. 

1 5 28. The method of Claim 26, further comprising; 

setting said policy specification to an initial policy, said initial policy 
comprising predetermined requirements and predetermined network 
credentials of said network. 

20 29. The method of Claim 26, further comprising: 

setting said policy specification to an initial best policy, said initial best 
policy comprising a predetermined set of credential and rules, setting all 
dispositions to DENY, and monitoring said network to determine ultimate 
dispositions. 

25 
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